A new policy-based arbiter prototype and a draft of an interoperable lexicon for group servers.
This is really just some quick thoughts, but recently I saw a couple of posts / threads about the "everything app" concept.
I believe having good abstractions is key to writing good code. But as a coder, I often write code in an effort to find those abstractions…
But it's also good — Musings about the last year of Roomy development, and more.
The permissioned data proposal has the concept of membership, but leaves it to the app to orchestrate it. The arbiter is our idea for a general-purpose, interoperable ATProto group membership service.
We've said Roomy's server was like a PDS, but what if it actually was a PDS?
So you want to make a PDS? Or maybe you want to watch some poor fool try? In this series I might make a PDS, or not.
So you want to make a PDS? Or maybe you want to watch some poor fool try? In this series I might make a PDS, or not.
For the last year, we have been working on Roomy with a clear integration to the ATProtocol. At the same time, we've also had a distinctly "off-protocol" strategy for data handling: we don't store Roomy's canonical data on the ATProto PDS. The reason for this is that the PDS because has shortcomings, such as a lack of private data, that make it unsuitable for Roomy's needs.