Nice! I also noticed that one of the versions of Patchwork didn't load images when I was offline, even though I'm sure I had the blobs for those images. Maybe a newer version of Patchwork fixed this
Lot of feedback! Thanks! Let me try to address most of them.
Rooms can have strangers in them, so users may want to avoid looking into the rooms to avoid abuse, but still be connected in order to sync with the people they care about. – @cinnamon
True, and I think this capability would be covered by ssb-tunnel as it is now, see this design document. Rooms implement a muxrpc plugin that is compatible with ssb-tunnel, so I'd say there are ways of achieving that privacy in some specific configuration of ssb-tunnel, not necessarily rooms. Rooms are public tunnels, essentially, but not every tunnel is a room.
Rooms in a DHT (discovery-swarm) – @cinnamon and @Christian Bundy
That would be a great idea, if discovery-swarm was reliable enough. It's a DHT that sometimes works, depending on your device, carrier, NATs, etc. My motivation for doing rooms over normal servers as opposed to DHTs is we need something that works 99.9999% of the time, 95% is not good enough. I sometimes notice Dat also not finding peers, I have to sometimes try out Dat over some different kinds of VPNs. And the next iteration of the DHT, hyperswarm is also not that much more reliable. Hopefully in the future once the p2p community has a 98%+ reliable DHT, then we could easily build rooms over DHT.
@skyebend: naming is hard, I had a bunch of name suggestions, but kept coming back to "room" for its simplicity and familiarity with the concept of "chat room".
On trackers, TURN, STUN, etc: I don't understand those so well, so thanks for the links, I'll take a look and try to learn something. :)
@cft I don't understand how you think this is a hack. It's very similar to replication over LAN, so it's very scuttlebutty. Rooms model the same flow of data as LANs do, the only difference is that the scope of a LAN is a location in common for the peers involved, while the scope of a room is an interest in common. SSB's forwarding fabric would still be preserved: Alice connected with Bob can ask for Carla's data, even if Carla is offline. And even if Carla is currently online, but on a different room, messages can be gossiped from Alice to Carla. E.g. Alice--Room1--Bob--Room2--Carla, notice that Bob can be in multiple rooms simultaneously. I mentioned ephemeral data and IM use cases as an additional bonus, it's not the primary reason for this proposal, and it's not a new thing to mention, we've been talking about ephemeral chat as a consequence of ssb-tunnel for a long time (years, I would say).
Proposal: Room servers
Stage 0 - Letter of intention
What do you want to build?
I'd like to build a new type a server – called rooms – that stores no persistent SSB data whatsoever, but allows currently online clients to replicate SSB feeds with each other. Once a client connects, it asks the server who else is online on that server; the server responds; then the client can connect to other clients. This would use SSB tunnel to create an encrypted channel between two clients in such a way that the server cannot decrypt the data sent back-and-forth between clients. Rooms are like the LAN sync experience (find SSB accounts around you), except online.
Why do you want to build that? What problem does it solve?
There are two problems I'm trying to solve with this: (1) increase the amount of servers and/or create more incentives for people to start their own servers, (2) improve the onboarding experience and opt-in discoverability of new users.
Problem (1) has to do with decentralizing server capacity. If operating a server has the risks of hosting undesired data or data from strangers (this is the case for pubs), then we won't have that many servers, and maybe in some decades SSB would become centralized. If setting up or maintaining a server requires dev ops skills (this is sometimes the case for pubs), then we won't have that many servers and we could become centralized. If a non-technical end-user doesn't see a direct benefit in setting up a type of server (this is the case for Rabble's phonebook directory idea), then we won't have that many servers and we could become centralized.
Rooms could easily represent communities: you could set up a room server for each topic of interest, and then people joining that room share the same context or interest. This is the incentive part for end-users to setup their rooms. And because rooms would have no persistent storage, there will be less concerns about hosting sensitive data.
Problem (2) has to do with decentralizing the bandwidth burden of onboarding. A lot of people who join scuttlebutt are not comfortable with sending invites to friends that they already have, but instead they want to make new friends on a new platform. They often look for large pubs with open invites, and this has the problem of sending them a huge amount of data from various feeds, which takes a couple hours to onboard, and in this process many people lose interest. Those that persist til the end are not sure what kind of content they got, and from who. From the perspective of a pub operator, the pub's storage quickly fills up and can crash the server.
Some years ago I made easy-ssb-pub with open invites, and I regret deploying it. But if we allow open invites on some rooms servers, then those rooms become places to discover and connect with new people. A user who connects to that room would not fetch a humongous amount of data, but instead would pick some peers currently online, and follow them to get their data.
What are potential impacts of this proposal regarding social, economic and cultural aspects?
Social: with a larger amount of servers operated by a wide variety of persons, we should have less of the Rando problem. First of all, rooms would not be followed, they are not SSB accounts like pubs are. If you have hops=2 configured, and you follow some pubs, then you will get data from everybody on those pubs. But if you join a room, the client-server connection with the room does not count as a hop, so you only get data from other clients in that room that you chose to explicitly follow.
Social: rooms only work if there are other clients online at the same time as you are. In many cases this should work but there are also cases where that would not work.
It should work if you are online for at least 1 hour, and if you follow a decent amount of people, for instance the Dunbar number (150). It is highly likely that one of your friends might be online at the same time. If not, then maybe the next time you go online there will be one of your friends online. I have already noticed this in scuttlebutt, that while I'm using it, people are posting new messages and likes, and these are being transmitted through pub connections in near realtime. Also, even if only Bob is online, I can still fetch the latest data from Bob plus Bob's friends.
However, if your social circumstances are such that all of your friends are in a different time zone than you, or you go online for a very short time, then it is possible that you won't see other peers currently online. This is the downside of rooms. However I don't think that rooms wouldn't entirely replace pubs, so for these use cases we could rely on pubs. It is nice to think that pubs and rooms are complementary.
Economical: I intend to recommend Mikey's Digital Ocean installer for people who don't have server operation skills, so they can quickly start up a new room server just by following a simple click-based UI. This only works for DigitalOcean, though. This could be a problem that it favors that cloud provider much more than the others, and it could make all (or a majority of) rooms vulnerable to DigitalOcean's policies. If this rooms idea catches on, I hope we could develop easy click-based UIs to set up the rooms in other cloud providers.
Cultural: rooms will add aspect of "places to hangout" to the SSB ecosystem, and might help support communities that want to stay focused around a specific topic. Rooms are also step one for implementing client-to-client ephemeral communication such as IM chat or off-log communication or throw-away messages.
Show whole feed