search

ssbc / ssb-bfe

Binary Field Encodings (BFE) for Secure Scuttlebutt (SSB)
3 stars 1 forks source link

Update spec with necessary URIs #30

Closed staltz closed 3 years ago

staltz commented 3 years ago

This library supports URIs but includes URIs that are outside the spec, such as:

For each of these cases we need to:

  1. Check if there are any downstream dependencies of ssb-bfe that actually need support for such SSB URI (I suspect no one is using gabby-grove SSB URIs in JS world)
  2. Drop support for such URI if (1) found no use case
  3. If there exists a use case, we need to update ssb-uri-spec and ssb-uri2 to add official support for that URI

cc @mixmix

mixmix commented 3 years ago

I'm using pobox already in Āhau.

I don't see why the specs have to include these exactly. Is it not sufficient that the uri spec says you go

ssb:some/thing/else...

We don't have to register every uri on the web for it to be useful and work yes?

On the other hand identity/pobox MUST be followed by a base64 encoded (and the uri mutated!) string to be useful. But in the spirit of free listening I'm checking for that with regex before ingesting. In reality you have to check this anyway, so what does the spec get us? A clear way pointer to how and why something exists and how to parse it?

I'm thinking out loud here

staltz commented 3 years ago

(For context: Mix and I shared some audio messages back and forth, and I'll also post here for transparency)

In a decentralized space we should have the freedom from global registries, yes. But a protocol is almost by definition a consensus mechanism, and we have to admit that we need consensus on some things. BFE and SSB URIs are basically the same, just that one is binary, the other is strings, and they are at the core of the protocol because they define the shape and semantics of data being passed back and forth between peers. And our protocol is centered around the data, because of the gossip propagation design. If we aren't careful about seeking consensus for the shape of this data, we may end up doing something pragmatic that in the long run will haunt us and hurt interoperability, such as the choice of V8 JSON stringify deep in the signed message format.

In the example of pobox, just doing it without seeking consensus is a pragmatic choice to get things done, but it's also a way of forcing consensus by being the first implementation so that other future implementations should attempt to be compatible with the first one. Currently it seems like Āhau is isolated from the wider SSB ecosystem, but we don't know if that's going to be true in the future too. What if Āhau makes a library with these URIs and then another app comes along and uses that library, and this app interoperates heavily with the wider ecosystem?

(If you truly want to create the isolation, I recommend using ahau:// instead of ssb://)

Is it not sufficient that the uri spec says you go ssb:some/thing/else...

As an analogy, it's not sufficient that HTTP servers just agree that 200 is a success and 400 responses are errors, all peers speaking HTTP have to agree on all the sub types under 1XX, 2XX, 3XX, 4XX, 5XX.

We don't have to register every uri on the web for it to be useful and work yes?

We do. URIs are registered here https://www.iana.org/assignments/uri-schemes/ and domains are registered with DNS providers.

In the end, I'm not asking for much. Updating the spec repo takes less keystrokes than what we spent writing these issue comments. I just want us to make it clear what are the consensus points, before we start diverging and create competing standards that are hard to bring back together when we desire interoperability.

staltz commented 3 years ago

In private, @mixmix said "Yeah feel free to add them now. I will keep this in mind when using uris in the future." so I'll go ahead and add the two private group related SSB URIs to the URI spec.

mixmix commented 3 years ago

I also said "I feel like bfe and uri specs are part of the same spec - they just define ways to represent the same idea is string or buffer"

With this module encoding and decoding from / to strings this is clearly tightly coupled with the other spec. Maybe we should make them one meta spec

staltz commented 3 years ago

I was thinking about that, and I think it would work better if we just link one spec to the other and vice versa.

There are URIs such as room invites etc that don't make any sense as BFE.