-
Notifications
You must be signed in to change notification settings - Fork 535
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
[SIP008ext] An SIP008 Extension for Other Protocols #168
Comments
Discussion thread for SIP008: #89. |
I haven't been following all the fuss around SIP008 but my thoughts:
Finally, regarding this issue specifically, this repo is for discussing standards for Shadowsocks so I find this to be awfully off-topic. |
One could even argue the fact that shadowsocks-android supports non-standard JSON documents as subscriptions is becoming a maintenance hell for other clients. Users are already expecting other clients to support the same file formats ss-android supports.
Extending our standards to be used by other protocols of similar purposes can help build a better ecosystem for everyone. Personally I wouldn't set such a narrow boundary for what we could do. |
You need to be able to extend more easily and possibly combine things. I suggest using typed objects. For example:
Then you could have a type "vmes" or a type "list" Lists are actually interesting. We should be able to specify how to pick the server from the list. Should it be the first one that works? Rotate? I can imagine something like:
or
You could also make fun things like tunneling:
To know whether you can support a config, all you need to know is what types you support. We could move plugins out of shadowsocks:
|
I agree we should be more innovative when defining the file format. But dramatic structure changes can break compatibility with existing SIP008 clients. This proposal aims to add extensibility while maintaining compatibility with SIP008. About the way of picking servers, I want to add that clients should probably also allow users to override the delivered behavior. Shadowsocks-rust already accepts a config format that's also compatible with SIP008. It uses latency tests to determine the server with the fastest response and switch to it transparently. Existing connections are not forcibly closed. |
Superseded by Open Online Config 1. |
To expand SIP008 to support protocols other than Shadowsocks, I'm proposing an SIP008 extension.
This extension would effectively make SIP008 a universal online configuration delivery standard, with registration requirements for unification and to maintain compatibility.
Overview
The SIP008 extension derives from SIP008 and is compatible with SIP008. The extension defines a new
protocols
field as an array element that contains all protocols the servers use.The
ss
protocol is reserved for Shadowsocks. Other protocols must be registered with an approved standard document. See the protocol registration chapter for more information.All requirements specified in SIP008 must be followed. An SIP008ext JSON document is also SIP008-compliant. That means an SIP008-compliant client can read Shadowsocks server configurations from an SIP008ext JSON document. Non-Shadowsocks servers are ignored and will not cause issues.
An SIP008ext client must check the
protocols
fields to verify if all protocols contained in the document are supported by the client. If not all protocols are supported, the client should import all supported servers and throw a warning with a list of unsupported protocol names.An SIP008ext JSON document may be comprised exclusively of servers of registered protocols.
If only Shadowsocks servers are present, you may or may not include the
protocols
field. If you do include the field, thess
protocol must be specified.JSON Document Format
Disclaimer: Some protocols in the preceding example are only for showcasing. They may have not been registered yet.
Protocol Registration
SIP008ext:<protocol_name>
. For example, a registeredvmess
protocol would be referred to asSIP008ext:vmess
.The text was updated successfully, but these errors were encountered: