[SIP008ext] An SIP008 Extension for Other Protocols

[database64128]

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, the ss protocol must be specified.

JSON Document Format

{
    "version": 1,
    "protocols": [ "ss", "vmess", "trojan-go" ],
    // Shadowsocks servers
    "servers": [
        {
            "id": "27b8a625-4f4b-4428-9f0f-8a2317db7c79",
            "remarks": "Name of the server",
            "server": "example.com",
            "server_port": 8388,
            "password": "example",
            "method": "chacha20-ietf-poly1305",
            "plugin": "xxx",
            "plugin_opts": "xxxxx"
        }
    ],
    // VMess servers
    "vmess_servers": [],
    // Trojan-Go servers
    "trojan_go_servers": [],
    // Optional fields for data usage:
    "bytes_used": 274877906944,
    "bytes_remaining": 824633720832
    // You may add other custom fields in the root object.
}

Disclaimer: Some protocols in the preceding example are only for showcasing. They may have not been registered yet.

Protocol Registration

• Prerequisites: You must be actively involved in the design and/or implementation of the protocol to qualify for the registration. If the protocol is managed by an organization or a company, anyone approved by the entity to represent them qualifies.
• Process: Reply under this issue to register a protocol name and reserve a field for your protocol. Once registered, you must provide a standard document with detailed definitions of the field within 5 days.
• Requirements: The standard document must be in English. The proposed field must be compatible with SIP008 and existing registrations.
• Publication: Once the registration process is complete, your registered protocol and a link to the standard document will be published to our website as a part of the official standard of SIP008 extension. You may refer to your protocol as SIP008ext:<protocol_name>. For example, a registered vmess protocol would be referred to as SIP008ext:vmess.

[database64128]

Discussion thread for SIP008: #89.

[Mygod]

I haven't been following all the fuss around SIP008 but my thoughts:

1. The way shadowsocks-android implemented subscriptions is very extensible, in particular, it already supports this kind of thing minus the optional fields.
2. From what I have seen, every subscription provider has a very different and opinionated way of doing configurations so standardizing it (especially every detail of it) makes no sense. This issue is a prime example of the endless maintenance hell started by [SIP008] Online config #89. The subscription provider should probably just fork off the clients and work on those instead.

Finally, regarding this issue specifically, this repo is for discussing standards for Shadowsocks so I find this to be awfully off-topic.

[database64128]

The way shadowsocks-android implemented subscriptions is very extensible

This issue is a prime example of the endless maintenance hell started by #89.

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.

this repo is for discussing standards for Shadowsocks so I find this to be awfully off-topic.

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.

[fortuna]

You need to be able to extend more easily and possibly combine things. I suggest using typed objects. For example:

"config": {
  "type": "shadowsocks",
  "server": "...",
  "server_port": "..."
  ...
}

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:

"config": {
  "type": "round_robin_list"
  "list": [
    // list of server
  ]
}

or

"config": {
  "type": "fallback_list"
  "list": [
    // list of server
  ]
}

You could also make fun things like tunneling:

"config": {
  "type": "tunnel"
  "dialers": [
    {
      "type": "http",
      ...
    },
    {
      "type": "shadowsocks",
      ...
    }
  ]
}

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:

"config": {
  "type": "shadowsocks-plugin"
  "opts": ...
  "server": {
    "type": "shadowsocks",
    ...
  }
}

[database64128]

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.

[database64128]

Superseded by Open Online Config 1.