Replies: 8 comments 20 replies
-
Direct connectionsA powerful property or Roomy is that users build up their own contact books of direct connections with one another. Roomy connects directly to your contacts' PDSs so that there is no hard requirement on a middleman. That said, the PDS is not suitable for realtime communication, so we currently use a WebSocket routing server for live chat. Eventually we hope to allow the PDS to specify what mechanism should be used to connect to the user for realtime chat, such as our routing server, another routing server, WebRTC, or other options. The goal is to provide as much possibility for optional decentralization as possible, so that it's not up to 3rd parties whether or not you can connect to your contacts. |
Beta Was this translation helpful? Give feedback.
-
p2p savingsRoomy runs more cheaply than traditional chat software because of its p2p underpinnings.
HostingI'll go over all the things that need to be hosted for roomy. FrontendThe first thing is the JS frontend ( this repository ), which is a SvelteKit app written with TypeScript. This is just a fully static SPA / PWA, so it can be hosted extremely cheaply and we could package it up as a tiny Tauri app and downloaded locally. There are ways to host this completely free like CloudFlare pages, which we use right now. Unfortunately GitHub Pages doesn't support SPA routing fallbacks, so we might want to add a way to build the app to use the KeyserverThe keyserver is a tiny service ( 120 lines of code ) that resolves AtProto DIDs to public keypairs, and generates private keypairs that can be downloaded if you authenticate. This provides a solution for the fact that AtProto identities don't currently have a signing key that their owner can access and use, like is needed by our future sync protocol. The service is currently hosted on the free-plan of Deno Deploy. It will be possible for users to use their own keys, declared on their PDS, instead of the one hosted on the keyserver, so that the keyserver doesn't have access to sign for them. It's also possible for others to host a keyserver, so we might let the PDS specify an alternate server keyserver to fetch it's key from. Having the keyserver as it's own tiny microservice helps mitigate some of the risks of a service that has everybody's keys, since it is trivially auditable and doesn't have any other concerns than the keys themselves. ResolverWe also host a microscopic ( 26 lines of code ) DID resolver. This simply resolves user handles to DIDs, which is a task that can be done by any PDS. It's considered good practice to host your own for your app, and it fixed issues resolving non-bluesky PDSes. This is also running on the Deno Deploy free plan. RouterThe router is a small ( 478 lines of code ) service that connects all of the clients online through websockets and routes the different clients' messages between them. This must be run on our own server because it is long-lived and requires keeping track of all of the online clients in memory. Since it's also forwarding all messages between all clients, the bandwidth requirements might be somewhat high with a lot of users. Soon, for clients that support WebRTC we will be able to make the router act as a signaling server and avoid taking up bandwidth for all of the peers connections. This should work for most clients and dramatically reduce our bandwidth usage. We will have to investigate different ways of doing the "matchmaking" that it performs currently in a more distributed fashion, but we can probably handle quite a few connections without modifications as is. I imagine that it can run reasonably on a $5/month server, we just don't know how many users that will scale up to yet. Also, since right now we don't have a way for there to be multiple routing servers, every single user in the network has to use the same one if they want to chat with each-other at all. We'll work on improving this. |
Beta Was this translation helpful? Give feedback.
-
Divide between browser & native appsRight now the bulk of the code is all in the JS frontend. Making native apps will not be hard if we can re-use the JS frontend using something like Tauri. Then we can also add additional connectivity mechanisms to the Tauri version to make it more p2p than we can in browsers, for example enabling LAN or bluetooth chat or skipping some of the web services like the resolver, which can be done locally outside the browser. Eventually with Leaf we might have more of a standard SDK that we could use to access more common functionality between the TypeScript and Rust versions of the sync protocol with Leaf + Beelay, but we're just not sure what the landscape is going to look like yet. |
Beta Was this translation helpful? Give feedback.
-
wouldn't we just want any room to also work on LAN as a fallback? |
Beta Was this translation helpful? Give feedback.
-
Yeah, that should be possible. I realized that we lose the ability to authenticate when we're offline, so if you lost your AtProto login session we wouldn't be able to re-check it. But that's actually probably not a problem, we'd remember who you were previously logged in as, and we'd just re-log-in once you're online so that we can sync to the PDS again. I think it would also be handy to be able to chat over LAN without needing an AtProto login, as a separate feature. Like, you might want LAN rooms that are intentionally not synced publicly outside the network and don't need any real auth because it only works for people on the local network anyway. It's cool to be able to use the same app for only-in-house chat and public chat. |
Beta Was this translation helpful? Give feedback.
-
I agree, though that feels to me like it’s best addressed by an Account Switcher sort of UX, rather than adding a whole section in for a feature that is very niche. Although I suppose if we only popped it out when you’re in LAN-mode it’d be fine, but that’s kinda my point about the account-switching, i.e. you’re switching to LAN-mode by switching to your local-first account. Not super concerned with how exactly v1 of this gets built anyway though. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, yeah, an account switcher UI would be perfect for that, good idea. I like that it clearly demonstrates that it's disconnected from your PDS account. |
Beta Was this translation helpful? Give feedback.
-
|
More on local-first accounts: https://www.localfirst.fm/17 |
Beta Was this translation helpful? Give feedback.
-
Fully Private DataSync Server ( Future )Eventually we'll have "sync servers", which will actually store chats and will be able to provide private, non-public storage for chatrooms. These may be required to improve performance for larger chat groups. They will be hosted by us as a paid service that can also be self-hosted. They will not require lots of resources, but will need more resources the more people you have using them, and storage for all of the chats ( chats are tiny ), and media ( more expensive ). Public groups could store media on the user PDSes, which could be a good option for free storage. The sync servers will be Automerge + Beelay + Leaf servers written, most-likely in 100% Rust. LeafWe're not sure how much Beelay will provide around questions like "what is a private personal data store", so Leaf may fill in some of that in a more opinionated way. We do plan to have Leaf personal stores ( ooh, maybe we can call them LPSes ) as something independent from AtProto PDSes, and fully functional without AtProto. They can act as an improved efficiency because they are sync-native, or as a privacy sidecar to AtProto, but they may not conform with typical AtProto lexicons, and we will probably have our own data model and possibly schema system that. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
PDSes are very much a "place", and the Beehive (soon to be renamed "Keyhive") orientation is oriented around data (it's a CRDT). We call our approach auth-as-data in opposition to auth-as-place. As such, Keyhive has no opinion about personal data storage physical location per se, but more about if a peer has sufficient rights. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, thanks! That works great for us because that means we can wrap any sort of "place-ness" that we want around Keyhive for the sake of user-experience / needs in different applications. PS: I like the name Keyhive! Feels nicer to say than Beehive for some reason, and is a fun play on words. |
Beta Was this translation helpful? Give feedback.
-
💯 yeah that's how we think about it; you can enforce placiness but don't have to
Thanks! 😄 🎉 |
Beta Was this translation helpful? Give feedback.
-
IdentityAdd any website
This is going to take some investigation. The thing that ties us most strongly to BlueSky right now is the use of their DID mechanism. The challenge is that we need to come to some solution for a longer-term identity than just owning a domain. BlueSky's plc.directory / DID PLC provides that. You can change your domain without losing your identity. I'm not sure exactly what the future is here. We may need a temporary way to support multiple identity solutions. Making a custom DID, possibly for OIDC might make sense as a solution, so that we could use DIDs as our universal ID and then support multiple methods like Weird OIDC and BlueSky PLC. We'll need to do some more research in this area, but our underlying data is portable so, with enough work, we should be as flexible as necessary. |
Beta Was this translation helpful? Give feedback.
-
If that helps us avoid some undesirable complexity to get started, we may as well. We don’t have to go deep on this for a while still though; can leisurely map our options first. Some contenders for off-the-shelf solutions: Reading materials |
Beta Was this translation helpful? Give feedback.
-
|
Our solution: use the atproto PDS as our new OAuth server for both Roomy and Weird (which is being refactored into a Roomy plug-in). We start |
Beta Was this translation helpful? Give feedback.
-
Federated roomsI think this is a great idea! As for what it would look like technically, it doesn't fit well into the way we do things right now. Our synchronization happens across relatively large "documents" such as entire chat spaces, and data is very easy to move / sync within that space, but not across the space. I believe that Beelay can change this, so once we have Beelay in place for experimentation, it might unlock federated rooms, maybe even very easily, but we'll have to wait and see. |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking we could maybe do a first pass of ‘faux-federation’ via atproto-net and/or plain client-side tricks. No actual federation needs to be taking place, we’re just displaying the same collection of rooms in a few different spaces (domains). |
Beta Was this translation helpful? Give feedback.
-
|
🤔 Yeah, we might be able to do something sneaky. Like I suppose we could have one space end up the "home" of the channel, and then secretly have the app join the user to the "home" space, just without showing the rest of the space to them in the UI, if a federated channel is added to another space that they have joined. It's a little "wasteful", but it's all kind of wasteful and needing to be worked out right now anyway, so that's not really a problem for now. |
Beta Was this translation helpful? Give feedback.
-
|
We could also start by having these shared spaces (might not even need to call them federated) be set up as standalone spaces by necessity. That might simplify the access-security model as well as being less wasteful. So in the case of Muni's protocol rooms collection for instance, we would indeed be the owners of that shared space (much like public list/feed curators on bsky), but we would host two spaces separately:
..and Muni Projects would be just another subscriber to that shared SWP space, embedding it as a collection. |
Beta Was this translation helpful? Give feedback.
-
|
Excellent answers, tyvm 🙏 Do you have any other noteworthy novelties you think we should bring attention to? I added Message Gardening and Anti-urgency. |
Beta Was this translation helpful? Give feedback.
-
|
No other thoughts yet, but I'll keep thinking about it and drop anything new here. Good prompts, BTW, thanks! |
Beta Was this translation helpful? Give feedback.
-
Anti-urgencyWe probably want to put this note somewhere else long-term, but we've chatted about the idea of possibly using What I like about this pattern is that it still easily allows you to ping when you want to, but it also clearly changes the default, so that you have to intentionally escalate the ping if you want to actually try to get somebody's attention in a more eager way. We've also mentioned the pattern of doubling an icon / symbol as a way to indicate extra confirmation for read receipts: This might be a pattern to lean more into in the UI as a way to indicate gradual escalation or extra confirmation. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Continuing from https://blog.muni.town/roomy-chat-alpha/
@zicklag please start a new post for each of these below with your (first short draft) elaborated explanations, so they’ll have dedicated sub-thread discussions.
Present
Direct connections
A powerful property or Roomy is that users build up their own contact books of direct connections with one another.
p2p savings
Roomy runs more cheaply than traditional chat software because of its p2p underpinnings.
Message Gardening
Anti-urgency
https://blog.muni.town/cozy-community-software/
Speculative
Fully private data
Roomy operates its own sidecar that hooks into ATproto. This a might allow for completely private content.
Add any website
Theoretically our user accounts and social graph and shouldn’t be limited to Bluesky profiles. Rather, it could support any account system that implements website-based names, which includes Weird.
https://blog.erlend.sh/indie-social-sign-in-could-go-mainstream
Federated rooms
https://blog.muni.town/federated-webrings/
The Muni space has a collection of channels that aren’t specific to Muni, and as such could easily appear as a federated collection in other spaces as well, thus making those rooms more inclusive.
I think the v1 of this would be a two-step approval:
federate:yesBeta Was this translation helpful? Give feedback.
All reactions