SSB URI for bendy butt IDs

staltz commented 3 years ago

This is just a conversation starter, not a clear "issue".

Inviting: @mixmix @arj03 @soapdog @cryptix

Context

In %4rYUo+HsLjz6vrfYS7jzJuAZ+0FiS31KWoNa+Nb3GYE=.sha256 @mixmix was brainstorming some options for a new type of sigil link, meant for "P.O. Boxes", a way of sending a private message (from anyone) to a private group.

He suggested

$G98XybiXD/amO9S/UyBKnWTWZnSKYS3YVB/5osSRHvY=.pobox

And then I suggested the possibility of using SSB URIs (see spec) instead, such as:

ssb:pobox/diffie-hellman/G98XybiXD_amO9S_UyBKnWTWZnSKYS3YVB_5osSRHvY=

And then it suddenly occurred to me that we should be in the process of deprecating sigil links and using SSB URIs instead.

Situation now

We're currently using, in this meta feed spec, the sigil link for bendy butt identities as such:

@+oaWWDs8g73EZFUMfW37R/ULtFEjwKN/DczvdYihjbU=.bbfeed-v1

This new sigil requires carefully changing code in the SSB stack to handle both .ed25519 suffixes and .bbfeed-v1 suffixes. Any code that does str.startsWith('@') and/or str.endsWith('.ed25519') is a candidate.

Proposal

We could freeze all sigils, not introduce any new sigil, and begin using SSB URIs. So for meta feeds that would be

ssb:feed/bendybutt-v1/-oaWWDs8g73EZFUMfW37R_ULtFEjwKN_DczvdYihjbU=

In practice, these would be found in main feed messages such as

 {
   // ... other msg.value field ...
   content: {
     type: 'metafeed/announce',
-    metafeed: '@FEEDFEEDFEEDFEED.bbfeed-v1',
+    metafeed: 'ssb:feed/bendybutt-v1/FEEDFEEDFEEDFEED',
     tangles: {
       metafeed: {
         root: null,
         previous: null
       }
     }
   }
 }

As a bonus, these SSB URIs were designed (led by @christianbundy) in a way that by coincidence happens to be similar to BFE, i.e.

ssb:TYPE/FORMAT/DATA

Which makes our work easy to convert from SSB URIs to BFE and back.

mixmix commented 3 years ago

we could make these even shorter too to be really BFE :

ssb:feed/4/-oaWWDs8g73EZFUMfW37R_ULtFEjwKN_DczvdYihjbU=

I like this because

a human reading it can see the "type" which is most useful thing
the "format" is not that useful, and can be compressed to use the BFE number
it forces programmers using it to use the BFE spec (which feels like a good thing to force, rather than guessing)

cblgh commented 3 years ago

i feel it should be said by someone: i think sigils are more appealing to see in posts than the longer, more complex ssb uris. is this just me?

not introducing more sigils or overloading existing ones makes sense, but i think it would be a mistake to prohibit the existing set from being used (as those are the ones people will see a majority of time in actual posts).

my concern is mainly one of aesthetics & the appeal of reading ssb posts; if anyone has proposals on how to hide the ssb:feed/<...>/ prefix when reading actual post-type messages in a consistent & gracious way, i'd likely be persuaded.

in this thread so far, i think @mixmix's proposal comes the closest in appeal to the original sigils:


ssb:feed/4/-oaWWDs8g73EZFUMfW37R_ULtFEjwKN_DczvdYihjbU=

taking this idea slightly further: could the TYPE and FORMAT fields be compacted into one? let feed be represented by 0x1 and bendybutt-v1 by 0x04 & we could for example have:

 ssb:104/-oaWWDs8g73EZFUMfW37R_ULtFEjwKN_DczvdYihjbU=

staltz commented 3 years ago

@mixmix if we're using numbers from BFE we should also use zero instead of feed, so ssb:0/4/FEEDFEEDFEEDFEED. I'm not fond of this idea, for two reasons: SSB URIs are to be the human readable variant to BFE, and the numbers aren't self descriptive, I can see this being a problem also when users want to know what they are about to open. Second reason is for coherence with the existing URI spec which has already committed to using words.

@cblgh I see what you're saying and I like @ for feeds too. I don't think % and & are equally aesthetic, and would prefer ssb:message/ and ssb:blob/ instead, but in any case I agree that we should support the classic sigils for the foreseeable future. Just important to not introduce new sigils, and to step up support for SSB URIs as first class.

mycognosist commented 3 years ago

I'm not fond of this idea, for two reasons: SSB URIs are to be the human readable variant to BFE, and the numbers aren't self descriptive, I can see this being a problem also when users want to know what they are about to open.

+1 to this. I think obfuscating the type and format in the URI will lead to a lot of confusion. Since this is a (Uniform) Resource Identifier - which ends up being user-facing - I think it would be a mistake to make it harder to identify at a glance. I don't think sacrificing humyn-readable meaning for URI length is a wise choice. Scuttlebutt is already inherently confusing; I would love if we could encourage understanding when possible.

As aljoscha mentioned in the URI mega-thread (%g3hPVPDEO1Aj/uPl0+J2NlhFB2bbFLIHlty+YuqFZ3w=.sha256):

Where URIs shine are as a format primarily intended for machines, but still human-[read]able (i.e. non-binary)

From the perspective of a (single) developer: I've been working with BFE and bendy butt for weeks now and I still haven't internalised the mapping of BFE to type-format. I can only assume developers will be more likely to make mistakes if the binary representations are used in the URI.

Regarding aesthetics, application developers could choose to represent the URI differently in their UI. Similar to anchor tags, where the href has the complete URI and the content has the shortened identifier. I realise this argument can be made both ways ;)

I agree that we should support the classic sigils for the foreseeable future. Just important to not introduce new sigils, and to step up support for SSB URIs as first class.

Agreed!

mixmix commented 3 years ago

I like how discord when you mention someone you briefly see the long id (uri) of a person then it swaps in the "short name"

I imagine rendering uris for identities by looking up the current preferred name.

Worth also saying that nothing is forbidden in ssb. But we're also trying to find common patterns which support the most people (eg are nice to use for humyns & aren't foot guns)

arj03 commented 3 years ago

I'm in favor of the proposal

staltz commented 3 years ago

One headache I found with SSB URIs: in ssb-db2, the author() operator uses a prefixOffset = 1, to remove sigils when doing prefix indexes. If we are storing both bendy butt (converted to JSON KVT) and classic messages in ssb-db2, then both of them will have {author} in the msg.value, and JITDB is going to lookup value.author for both of them when building an index for author().

If we had a field authorURI this would be easy to fix and make a prefix index with prefixOffset 7, but not sure if that's better if it'll also require changing code elsewhere to do author || authorURI.

soapdog commented 3 years ago

There are multiple things happening on this thread and I'd like to provide my view on some of them since I have been around the issues of SSB URL for a very long time.

I think that using SSB-URI is the smart way forward. It is more flexible than sigil links. We should avoid overloading or creating new sigils as the code to handle them is spread all over the place and it is sometimes clever doing inferences such as starts with (which I also have done in Patchfox).

That being said, the good thing about URLs is that they are human readable. I don't like magical numbers on my URLs, and don't want to process a part of it using binary math to extract what is actually going on. Because of that, I don't want to see things such as ssb:feed/4/... or ssb:104/.... It shaves a few bytes, but IMHO is the wrong kind of optimization. I'd much rather see a clear URL such as ssb:feed/bendy-butt-v1/.... SSB-URLs don't need to be short. No one is typing them by hand. Clients will generate their own links for them anyway and can present them in some nice <a> link with a good text node.

In my experience, having stuff such as ssb:104/ or ssb:4/ always hurt in the long run. They're harder to maintain because it is not immediately clear what those numbers mean. Besides that, someone will eventually write a startsWith("4") somewhere and once we reach BFE ID 44 we'll all have problems — which is exactly why there was no Windows 9, and they jumped from 8 to 10 — URLs are best when they provide a clearer picture of what they represent.

URLs don't need to be completely self-documenting, ssb:feed/bendy-butt-v1/... doesn't tell someone not familiar with SSB-URI what is going on, and that is OK, what they provide is a clear picture for those who know about feed URLs. Using magic numbers will cause even those who are familiar with feed URLs to have to check tables now and then to figure out what that number means.

It is not unlike why tags are more popular than plain old category IDs...

staltz commented 3 years ago

@arj03 Have you had time to think about https://github.com/ssb-ngi-pointer/ssb-meta-feed-spec/issues/19#issuecomment-895208243 ?

arj03 commented 3 years ago

@staltz yeah I was thinking that we could do this by adding a new findPrefixOffset option to find the offset instead of being only a static thing.

ssbc / ssb-meta-feeds-spec