You are reading content from Scuttlebutt
@Jacob %pRxE1EZkvzOXpJg+P618y4IKfNn7KQXe043xzLPRBrY=.sha256

Patchwork had the "copy web url" button when you right clicked a post. That was useful because you got a link that was clickable in most/all apps, since http links are well supported. The link took you to a hard coded (or were you able to change it in config?) web viewer running on a pub.

This had a few flaws:

  • Hard coded server brings a bit of centralization
  • At first, anyone on the internet was able to see almost every ssb post on the web viewer, a privacy issue.
  • After a while, the default was changed to posts being hidden except if the author had explicitly opted in, which no one did, making the feature largely useless

How about this user flow instead, manyverse in this case but could be any app:

  • You click the ...-menu on a post/user you want to link to
  • You click "copy web link" and in your clipboard you get a link that looks like this https://hermies.club/link?l=ssb:feed/ed25519/ed1T9mWlMAg2rfMG-r2j1yJaS7UIsZZox5SQFWNDAuc= . The room is semi-randomly picked from one of the last ones you connected to. (how do we know that the room supports this? discuss below)
  • You send the link in e.g. Signal to a friend.
  • Your friend visits the link and the only thing that page does is try to open an ssb-protocol-handler-compatible app on the friend's device and open the ssb link contained in the http link i.e. in this case ssb:feed/ed25519/ed1T9mWlMAg2rfMG-r2j1yJaS7UIsZZox5SQFWNDAuc=

@nonlinear has been sketching some advanced share-post-and-user-invite flows that look really cool. In my mind this proposal above would be the first step towards that. Once we have broker(?)/token room invites, you can imagine the above example link also containing a token, and when the user clicks the link they then can also e.g. get added as a member to the room, or a private group, or etc. That would be a super easy and compelling way to get invited to ssb.

@andrestaltz @nonlinear phone

@andrestaltz %NTH2IOgquwFBdfmkjIWTTWwz7RVjzK0E90+ZWIM9WDo=.sha256

@Powersource (pc) & (phone) This idea is kind of like generalizing room aliases!

I got inspiration for aliases from Telegram's t.me service, which is basically just a way of using Web URLs to get around the lack of parsability for wild URIs. Web URLs work great because they can always be clicked, no matter where you put them. E.g. https://t.me/example just opens a static HTML page which immediately tries to open the URI tg://resolve?domain=example. There should be a name for this pattern. For the lack of name at the moment, let me call them web-masked URIs.

So t.me is a web-masked URI. Room aliases are web-masked URIs. And so is your new idea.

Your idea is quite close to an idea I had for broker auth, but which is still not written on the spec. The spec currently only lists 3 use cases: inviting a friend to connect with you, bootstrapping data for a subapp ("sign-in"), fusion dance ("same-as"). We should add a 4th use case: sharing content from SSB.

The problem with bare URIs is that they just identify the content, they don't locate the content. So it's possible to share a URI (or your proposal of a web-masked URI) and end up opening the app just to see a "couldn't find message" popup, which is disappointing. And disappointments make for bad UX. Broker auth links for "sharing content" could carry several pieces of data:

  1. Room alias (this is the URL host part)
  2. Auth token (in the URL fragment, so the server can't know what it is)
  3. SSB URI to the content (in the query params)

The first two help your friend connect with you, and then the third says "now that you've connected with the person that has that content, you can finally open up the content and it'll replicate via the connected person".

Example https://staltz.hermies.club/?content=ssb%3Amessage%2Fsha256%2FpRxE1EZkvzOXpJg-P618y4IKfNn7KQXe043xzLPRBrY%3D#1b2a987ff8e3e985c. Breakdown:

  • https://staltz.hermies.club/
  • ?content=ssb%3Amessage%2Fsha256%2FpRxE1EZkvzOXpJg-P618y4IKfNn7KQXe043xzLPRBrY%3D
  • #1b2a987ff8e3e985c

(how do we know that the room supports this? discuss below)

One of the nice things we built into rooms2 was a metadata endpoint and muxrpc that you can call to ask which features the room supports, see https://ssbc.github.io/rooms2/#metadata-api

As another idea, which I'm not too serious about, is to build this web-masked URI on manyver.se. The upside is that it's just a static HTML page that renders in an <a> whatever is already in the URL query params, so there is no server-side logic that is collecting all of this. But the downsides, as you noted, is giving birth to centralization, as well as still having the "couldn't find message" disappointments I mentioned above.

@andrestaltz %tBn1Ppl3Dwihya5gwk8i8NieVD7M+ttBh1PJgZGdiIY=.sha256

For more context, here are two interesting diagrams related to invites:

@Matt Lorentz %V4nByWs0NS9gYIzfWOiJerojlb1lqZ2o7Ib1F48V0fY=.sha256

I like this idea! We have been wanting to do something similar in Planetary and have also been inspired by Telegram. I suppose there is nothing stopping us from implementing a similar scheme for pubs (although ssb-server doesn't currently serve anything over HTTP IIRC).

I think the thing with broker auth sounds great too, but I could see cases where you would still want to use the web-masked URIs, so implementing both seems reasonable. For instance if you want to share a link publicly but only want your SSB friends to actually be able to see the content. Or if you want to share a link to another user's content. Maybe these two types of links could be generated by the same UI with an "embed invitation" checkbox or similar.

Also ideally I think this would supplement and not replace the option to copy out a canonical SSB URI.

@ओषधिः %OWj91+TgZjcaINWEItI+ZNR00+R+RndaNEhAJGZfmnU=.sha256

I really like how https://matrix.to works and would be curious to see something similar for ssb

User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
@SoapDog (Macbook Air M1) %W7cxbVDthmk8s6VM2OEn+ZNZNH6/3E4+e2MLrF4YR0M=.sha256

@Powersource (pc) I don't understand what this workflow would bring to the table when compared to "copy link" getting you a ssb: link instead. It is just pinging a room and doing a redirect to the ssb: url, so why not simply copy the SSB url in the first place? If the reader has no SSB app installed, that http-to-ssb link will not work anyway.

What is that http link doing that a simple SSB link can't do? Is the problem being solved the fact that many apps will strip SSB links out of the text? Because if that is the case, then I totally understand why we want this. I just want to understand if that is the only motivation or if there is something else I'm not grasping.

User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
@Rabble %sfgI9Wp3x9EGSQqvWryZwFwSR0GwDcKZY0mUC+JP43w=.sha256

If we had a deep link to a web viewer like with rooms or a pub viewer it could display something about the feed of the person wanted, and information about how to load it in ssb via an ssb:// link or instructions on how to join ssb with this person as their first link in to the network.

Join Scuttlebutt now