-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mergable network config #24
Comments
another possibility is to have a layer for scope. connections: {
incoming: {
<scope>: { <name>: {transport,scope,... ,transform},... },...
}
} that would group every thing in the same scope together, which would make it nice and easy to merge. |
maybe... the solution is to allow an address to exist in more than one scope? hmm, I feel this might do it |
Yeah, like the multiple scopes approach. In general liking this PR. |
Hmm - scopes is starting to seem overloaded. |
+1 for With the config, the user wants to say
the scopes And with
Should we talk about For convenience, and so that sbot works out of the box, we could offer symbolic names for the first public and the first private address we can find. This would work like if the user had entries for
and then:
Since we are talking breaking change now:
|
That example you give has a lot of duplication, what if it was:
for transforms with properties, I suggest this structure:
Yeah, I'm also thinking of maybe |
I want to emphasize: It's important to be able to return multiple addresses: A pub should expose a net and a ws address (so that it's possible to connect from a browser). A public peer that isn't able to connect to a net address can just ignore that part, same goes for upgrading shs. I guess the thing is there is really two aspects here: groups of addresses that you want to share in different contexts (which was how I interpreted scopes - actually, arj came up with scopes because we wanted to make the pluggable transports stuff work with tor) and what interfaces to bind to - which became a problem once we introduced noauth. interfaces to bind to is specifically a tcp problem (okay, maybe udp too) |
so maybe interfaces to bind to is something that is handled by the specific plugin? |
D: uhm .... That's very high up on the list of utterly confusing key/value triplets! :) I like the linked list idea though ... (yes, arrays and merge don't go together well) Yes, groups! That's a much better term! You want to group the connection methods that are available for processes on your device, people onboard your boat, and people on the Internet into three different groups. But IMHO you dont want to specify the tcp host indirectly by giving the name of that group.
does it though? To be honest, I don't see a single duplication? "ws_device" is just a label/name without semantics. |
I'm not sure that "group" and "scope" really mean anything different, they are both so generic to seem interchangable to me. @regular each row duplicates:
I realized a thing just a second ago: I want to advertise a tunnel address - but not mix it with a public scoped net server. I could just make up a new scope - and announce that instead of "public". Okay, maybe you had already figured that out... but I still need a way for my net server to give an address in multiple scopes. I notice there is a weird exception that includes public scopes in private addresses: https://github.com/ssbc/multiserver/blob/master/index.js#L49 (I don't think there should be a special case there) And remember, several of the plugins were reporting their scopes incorrectly, like, ignoring config, which was fixed here: https://github.com/ssbc/multiserver/blob/master/index.js#L49 |
Ah, you mean it's redundant, when you want to listen on all interfaces? I see. the tunnel thing: In my world you would define your own named interface and advertise that. About https://github.com/ssbc/multiserver/blob/master/index.js#L49 I guess the reasoning behind this code (and I am guessing, since I'm not the author), is that when you are in the private scope, you can still reach the public scope. This way, for a normal setup, you only need a server in one scope: public. It can be reached from local, private and public. But the fact that you don't think that code should be there and someone else obviously thought it should be there, illustrates my main concern about the term "scope": there doesn't seem to be consent on the details of how they are supposed to work. Different people write code with different definitions in their heads, it seems to me. I would not say that "group" and "scope" are interchangeable terms. "group" defines a set of things, while "scope" is about the visibility of things. I want to define a group of interfaces that I can refer to in |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
as stated here I think we need a more flexible network config. we need to have default settings that may be disabled or overridden in a granular fashion. the current pattern only sets the connections defaults if the user hasn't set any thing, and if they set anything doesn't set any defaults. This causes the user to copy the default config and edit it, which means if we want to change the default config it still needs to work with the copied config. It would be better if the user updates only overrid the parts they wanted to change
other considerations
running more than one protocol instance per scope
you may wish to have more than one server on the same scope, with different protocols or different shs settings. those will go under a separate name, and you can disable them by setting
--connections.incoming.ws_public=
other scopes
ssb-device-address lets you announce an address for a scope. it can be encrypted, to only some recipients too, for example, you might not want the whole of the scuttleverse connecting to your ssb-tunnel but do want your friends to connect, so put that in a scope "friends". "work" might be another obvious alternative scope.
Also, bluetooth, and other local network IoT stuff might expand the set of scopes to non-ip protocols.
The text was updated successfully, but these errors were encountered: