ssbc/rooms2

Design doc for the next edition of SSB Room servers

• Intro
• Stakeholders
  • Administrator
  • Internal user
  • External user
  • Moderator
• Setup
  • Components
  • Privacy modes
  • Config database
  • Web Dashboard
• Participation
  • Joining
  • Internal user registry
  • Internal user authentication
  • Invites
  • Tunnel addresses
  • Tunneled connection
  • Tunneled authentication
  • Metadata API
  • Attendants API
• User aliases
  • Alias string
  • Registration
  • Revocation
  • Alias consumption
  • Alias web endpoint
  • Alias database
• Appendix
  • List of new muxrpc APIs
  • List of new SSB URIs

rooms2's Issues

alias resolver web endpoint

https://github.com/ssb-ngi-pointer/rooms2/blob/2cc7f84b34743c308f827b065be05fa966daaa94/docs/Alias/Web%20endpoint.md#L13

While I like the look of https://${alias}.${roomHost} very much, I'd prefer https://${roomHost}/${alias} for practical reasons.

The subdomain approach requires a wildcard certificate setup. For LetsEncrypt that means DNS-based challenge-response setup which is quite a bit more hassle to deal with (changing the TXT record of the domain). With the cert validity time-frame getting smaller over time this will basically require an integrated registrar with API support or admins will need to update it by hand every other week at some point.

Add revision or version to each generated PDF

License hygiene

HTML output as Github Pages?

With #22 merged it could be cool to have the current release as a github pages thing and not only a downloadable release maybe?

muxrpc namespace

@cryptix You mentioned that we could/should have APIs like rpc.room2.registerAlias. Currently this document specifies them as rpc.room.registerAlias, because rpc.room is not a namespace used anywhere so far. Instead, we have APIs under rpc.tunnel such as rpc.tunnel.isRoom and rpc.tunnel.announce.

We could adopt rpc.room2, but that leaves the space open for someone to use rpc.room, which could be confusing if the 3rd edition of rooms chooses to use rpc.room (because we'd have v1 using rpc.tunnel, v2 using rpc.room2 and v3 using rpc.room), so I'm kind of preferring to use rpc.room for v2, and otherwise referring to "rooms 2.0" only in spoken and informal situations.

What are your thoughts?

cc @arj03 @cblgh

Spurious ephemeral contact

Continuing the conversation from arj03/ssb-browser-demo#186

This was actually a very interesting case. It surfaced a bunch of assumptions about how SSB works with random connections both before and going forward. The sum up: this is by design in EBT, and rooms 2.0 will have the same model of tunneled authentication requires mutual follows. The really important thing here is to make that clear to the user I think. That would solve a lot of problems. It is actually a "hack" that it works right now for non-EBT transfers and we might tighten that up in the future so you can't do that.

Originally posted by @arj03 in arj03/ssb-browser-demo#186 (comment)

Hm. That's...troubling. That means that, for onboarding new users to SSB, rooms can never truly obsolete pubs. Otherwise it's forcibly invite-only and can never be made accessible to the general public. And there would be no way for potential users to look at the content posted to SSB to decide if it was worth joining.

The same would even be true for folks who had to reintegrate with the network after something like forking their feed. Unless they had an outside-of-SSB channel for communicating with someone that they should follow them, they'd be locked out. Which means that SSB can't realistically run in a vacuum like it otherwise could.

It seems like a very strange decision for something that's otherwise very well-designed for the free and open flow of information.

Originally posted by @KyleMaas in arj03/ssb-browser-demo#186 (comment)

Thinking about this more, requiring mutual follow also breaks the use case of a person travelling off the grid and getting updates from anyone and everyone they come in contact with. The ability to support spurious ephemeral connectivity is a huge plus for SSB - otherwise, there's far less reason to do chained message signing (instead of an independent per-message signature), since you have to establish a "trust" relationship with anyone you want to get messages from anyway.

Originally posted by @KyleMaas in arj03/ssb-browser-demo#186 (comment)

I think it would be best to have this discussion in the rooms2 repo. I'm sure Henry and André have input on this.

Originally posted by @arj03 in arj03/ssb-browser-demo#186 (comment)

The gist of this is: SSB is designed for off-grid use with only occasional contact with the outside world. By requiring mutual follow to replicate anything, it means that there is no such thing as a spurious read-only contact when coming off-grid. It means you can only contact the network through people you have a trust relationship with. This may be fine under normal circumstances but breaks down in several possible scenarios:

1. You are travelling the world and want to get updates on what's going on whenever you stop (seaport, airport, coffee shop, etc.). Because replication would require a mutual follow, you would have to establish a trust relationship with another person to be able to replicate, even if you both follow some of the same people.
2. You and another person both follow a third person, but the other person does not want to replicate your friends' feeds. They may not want to follow you and absorb the baggage that comes along with that, but you want to follow them. Because they don't want to follow you, you cannot replicate their feed (or anyone they follow) directly.
3. A new user is thinking about joining the network but is unsure. They want to take a peek into the content of the network and see if they like it. They join a room, see people in it, connect to one, and...nothing. They're new, so no one follows them, but in this scenario they can't even see anything on the network. They assume the network is empty/unused and leave.
4. You accidentally fork your feed and need to start a new feed. You're now in the "new user" scenario. Without some kind of an off-network contact to ask them to follow you, you normally wouldn't be able to post anything that anyone would see. But with a requirement for mutual follow, you can't even see what's going on. You're now dependent on some sort of external (and potentially long-range) communications mechanism.

This also means that rooms cannot truly replace pubs. There will always need to be pubs to onboard new users or people who have had to replace their feed. And these will continue to have a tendency to quickly become massive messes just like open-invite pubs with tons of follows do now. But with a mutual follow requirement, they stay the same "evil" but become even more "necessary".

In short, a "follow" is an implied trust relationship. You trust the other person to not shovel garbage into your database. I see the requirement to establish a mutual trust relationship with a stranger to be able to view publicly-posted messages to be a huge step backward. Why should they have to trust me for me to be able to read? I'm hoping maybe this can start a dialog on how to support these use cases, because I would really hate to lose the ability to safely replicate off-grid from strangers.

Alias web endpoint, and no alias resolution

alice.scuttlebutt.eu not @[email protected]

relation to STUN/TURN or sockethub?

this is probably a silly question, but wanted to ask in case it wasn't considered.

would it be sensible to use something like STUN/TURN for the tunneling parts of ssb-room? eg. https://github.com/coturn/coturn

failing that, perhaps building on something like https://github.com/sockethub/sockethub

are there other requirements, such as that the tunnel must be able to run from within an ssb-pub process?

"Sign-in with SSB" versus other alternatives

Problem

Internal users need to perform actions such as register alias, revoke alias, resolve other aliases, create invites, and moderators need to perform actions too, such as block some IDs, remove aliases, etc.

Possible solutions

(1) Sign-in with SSB

Summary

• Client goes to WWW interface for the room server
• Room calls a muxrpc API at the client's SSB node, to send a challenge
• Client solves the challenge and answer the muxrpc API
• Server grants the web user with access to a logged-in dashboard
• Client on the website can perform actions

Pros

• Very flexible way of doing actions in the room, can easily update the actions, add more, etc
• Only one muxrpc to implement in apps, for the challenge-response

Cons

• Have to think about all sorts of vulnerabilities that can arise with this new auth model
• When signing-in on the web dashboard, the client SSB app has to be up and connected to the room
  • Counterargument: the SSB app could provide a web link or button on the currently active room connection, thus guaranteeing that when the page is opened, the SSB app was just a few seconds ago actively connected with the room
• Are people going to get too excited about "sign-in with SSB" and try to apply it in other contexts where it's significantly harder? (e.g. sign into StackOverflow with SSB, requiring communicating between StackOverflow, room, user)

(2) Muxrpc APIs for each action

Summary

For each of those actions, there would be a new dedicated muxrpc API.

Pros

• No new system
• Proven way of doing actions across SSB nodes
• Seamless experience in the apps, because don't have to leave the app for the browser

Cons

• All apps which want to support Rooms 2.0 need to implement UI flows for all those actions

(3) Feed dedicated to tracing all actions

Summary

• Each room client creates a subfeed of their feed
• When issuing an action to the room, they create a message on the subfeed
• The room replicates the subfeed, executing the new actions
• The room also keeps its own feed for logging all actions successfully performed

Pros

• Traceability of all actions and their results
• If the room explodes, the room's feed could be replicated by peers, and thus is a backup when restoring the room
  • Counterargument: the secret would still need to be backed-up in a separate mode (this is true for all these solutions listed in this issue)

Cons

• All apps which want to support Rooms 2.0 need to implement UI flows for all those actions
• How much space does the room log and client subfeeds take? (space taken in client app's storage is the main concern, not storage space in the server)
• Part of this idea could be used with one of the other solutions above. E.g. an SSB feed for tracking changes applied in the room (for traceability and backup) could still be employed even if develop the "sign-in with SSB" web dashboard idea, or with muxrpc APIs.

[meta/PDF output] fix links and TOC

This isn't about the content but the presentation. I find it really distracting that the links can't be clicked leading to a lot of scrolling or fulltext search. Additionally a table of contents and proper document outline would be very helpful since it's a lot of small sections.

@staltz what do you currently use to turn it into PDF? The tools folder only turns it into one giant markdown document AFAICT.

Clarify cc/sc challenges in sign-in

Audit feed

Should the room have an SSB feed where it posts one message for each action performed on the room (e.g. via web dashboard)? This would allow easy backups/restore as well as allow easy audit of what was done.

At least one UML diagram needed

Clearify intended causality to follow after invite consumption

In general the document is saying "mutual follows are required to build a tunnel" but the document is scarce on how this will work for new guests/people consuming invites.

While the consuming side can follow the creators public key since it's on the tunnel address, it's currently not specified how this will happen for the creator.

So in general we need some mechanism so that the the consumer can tell the room their public key and then the room needs to notify the creator that the invite was consumed (and that new public key they need to follow/allow).

Two solutions come to mind with varying tradeoffs:

1. Have the creator check the room for consumed invites.
   Either via polling some HTTP endpoint or via some muxrpc source to be a bit more event driven.
   This might be a bit quirky or delay intensive. The client would need to remember some state for resumption. Sounds a lot like a log/feed.

2. Have the room send a SSB direct message to the creator.
   Easy resumption and even transport the notification across different routes, not just between room to creator.
   Downside: the room would publish stuff just for this one case(?) and not as ephemeral (with the current ssb feed format at least).

Appendix: list of new SSB URIs

Invalid joining link

https://github.com/ssb-ngi-pointer/rooms2/blob/main/docs/Stakeholders/Internal%20user.md links to Joining.md which is an invalid link

Update Security Considerations regarding DNS and TLS vulns

See cel's thread on SSB

Detailed spec

Probably need it for:

• Alias resolution
• Alias string
• Sign-in with SSB
• Tunneled auth

Probably don't need it for:

• Full alias string
• Alias database
• Host resolution
• Invite endpoint
• Alias registration
• Alias revocation
• Tunneled connection
• Web dashboard
• Alias web endpoint

Endpoint for compound user aliases

See the discussion at https://gitlab.com/staltz/manyverse/-/issues/1087#note_479441556

Specify how invite consumption actually works

JSON POST request to inform the SSB ID? (And response is a multiserver address?)

1. HTTP GET: User visits invite web endpoint
2. SSB URI: App consumes SSB URI containing the room URL for the POST request
3. HTTP POST: App makes POST request to inform its SSB ID, receives room's multiserver address
4. MUXRPC: App connects to the room via multiserver address

Or muxrpc:

1. HTTP GET: User visits invite web endpoint
2. SSB URI: App consumes SSB URI containing the multiserver address
3. MUXRPC: App connects to the room via multiserver address
4. MUXRPC: App calls a muxrpc on the room to claim the invite

alias resolve error schema

The web endpoint schema only defines the happy route but not what to do when an error happens (i.e. alias undefined).

Maybe we could require a status string as well which should be successful for known aliases and if it's not there can be an error string as well on the object.

Moderators can change the room's privacy mode?

The doc for the moderator dashboard says that moderators can
https://github.com/ssb-ngi-pointer/rooms2/blob/main/docs/Room/Moderator%20dashboard.md

Change the privacy mode of the room

This seems like a very powerful action, as it could completely change the meaning of what the room is for all of the users that had previously signed up. Maybe more appropriate for Admin role? (since Admin's hold the keys)

Update security considerations with regards to invites no longer using muxrpc

When poking @cryptix regarding vaguely specified behaviour in the spec, he noticed that the described security invite considerations was now inaccurately described, and wanted me to make an issue. Here's the issue!

(?) Split out SIWSSB as a separate spec