Apologies. My last post the big text was the title. But, we wanted to talk about the (unreleased) relay.
The relay is a federated service. A federated service means there's no single company controlling your data. Instead of all users connecting to one central server, anyone can run their own relay — including you, your community, or a trusted provider. In this case, it provides the transport functionality for the PluraslLog Client to PluralLog Friend relationship.
That said, we wanted to develop a model around our relay service — a demonstration of how it should work & look. We don't mean aesthetically & in terms of user experience, that's up to whoever chooses to implement or run a compliant server. Instead we want to focus on the mission — what should a relay be.
The idea in our mind originally was to have something that the user doesn't need to trust at all. I had recently been studying FHE, and it seemed like a good opportunity to try applying the principles. Safe to say, it's hard. There's a lot of holes, and it's easy to make mistakes when trying to reframe your design process around a principle you don't usually use. I am not, happy, with the result. But it's there, and eventually it needs to release.
Lead developer yap moment. In my mind, the biggest gaps are a lack of validation & a suspicion around the key exchange/sharing. For point one, the server *can* (Idk how to do italics) run without seeing the user's data; but is it. How do you know that the server isn't logging more than it should, or trying to run a cracked variant of the processes it should. Typically, there would be measures such as a ZKP Bulletproof, which is basically just having the server solve a hard problem you know the answer to within a certain time to prove it's using the correct steps/algorithm (simplification, but close enough). I want this moreso for relay to relay communication than the plain client, so I've seated it. The second point is me being scared I messed up. I, probably did. I want to note these two points, because I want to form the understanding that v1 of the relay will be optimistic — expect some possible setbacks or breaking changes to follow it. Breaking changes at the relay level are a low tier issue for the average relay use case (ignoring backups) because all data is stored locally to client devices; users have an easy time reconnecting, and operators aren't expected to manage individual data units.
That aside, let us show off what we've made!
First, the relay flow. To run the relay, a user just needs to:
- Generate an admin token; This is optional, but necessary to setup an admin server
- Generate or provide cryptographic keys - key.pem/cert.pem
- Pass them in & run
The relay server doesn't require additional configuration.
Then its endpoints are up. The admin dashboard server has either an env file or vars, that requires the user to:
- Add the Admin token
- Generate & add a bcrypt hash for the user password
- Provide the relay URL
- After that it's a matter of running a NextJS server.
We plan to release docker files to make this pretty straightforward, but it isn't difficult without them.
As for how the dashboard currently looks, I shall provide some photos. Here's the feature list:
Relay operators can see number of volumes (overall & by type), padded sizes of volumes, total storage (including metadata), but not contents of user volumes
Relay operators can see unique user IDs and selected handles, user occupied storage, whether they've registered as a friend or system. However - UUIDs are random & regenerate if the app is reinstalled, meaning users cannot be identified between relays or device migrations unless they opt to share that information or reuse handles. Because relays can be independently operated, a user handle is only reserved on a relay it's registered with, meaning users need to exercise discretion when sharing (friend handle doesn't mean friend).
Relay operators can see number of active friend links but not links themselves
Relay operators can see the sharing relationships that exist on the server, and what has been shared, but not the content of what's shared.
Relays have built in rate limits, but these limits can be configured. Relays support TLS, with self-signed or CA signed certs
Relay operators can see number of active sessions, can invalidate sessions in mass, cleanup stale data, and see unusual server/user behaviors (mass challenge attempts, connection IPs (unavoidable, relay specific policy), unusual storage growth) and can delete users from the server.
Relay operators can perform general maintenance, but cannot completely assist users due to the above restrictions.
Oh wait I copied bulletpoints from discord. I dunno if my other stuff is supposed to be bulleted but it isn't. Here are the images:
Apologies for the little ideological privacy notice in the dashboard, but this is largely meant as a demo. Adding the admin dashboard is our example of an extension to the base relay, adding features that don't compromise the core ideas. A relay operator could, especially with the lack of a bulletproof & crypto review, work to make a malicious relay server to expose data. We are, obviously, expressly against that. This wouldn't necessarily be easy, but I am unsure at present.
BYYEEEEEEEEE
