I'm curious about how the persistence primitives (OrderedTable, Table, etc) are implemented under the hood. Is it calling out to some other database service? Is it implemented in Unison itself? Seems like a really interesting composable set of primitives, together with the Database abstraction, but having a bit of a hard time wrapping my head around it!
Hey there! Apologies for not getting to you sooner. The `Table` is a storage primitive implemented on top of DynamoDB (it's a lower-level storage building block - as you've rightfully identified; these entities were made to be composable, so other storage types can be made with them). Our `OrderedTable` docs might be of interest to you: they talk about their own implementation a bit more (BTrees); and `OrderedTable` is one of our most ergonomic storage types: https://share.unison-lang.org/@unison/cloud/code/releases/23...
The Database abstraction helps scope and namespace (potentially many) tables. It is especially important in scoping transactions, since one of the things we wanted to support with our storage primitives is transactionality across multiple storage types.
The fact that all the data is open means not only that you could plausibly exit to other providers and keep all your projects data, (issues, prs, etc), but also that it's dramatically easier to build other tools that work on that same data. Triage, labelers, bots, etc, I know these are all possible on GitHub today with their API, but I think the programming model of ATProto removes a lot of friction in building and composing them.
I think there is a sort of thing built on top of Git where the wiki and issues are actually part of the repo itself, I forget the name, a bit like the Fossil SCM.
In my view the atproto approach asks the users to make fewer required complex decisions, but gives them the freedom to make many voluntary ones. If someone wants to use a particular application, they basically just need to sign in. If they don't have an existing ATProto account, they can just make one, in the flow of the application they're signing into. Later they can chose different clients, or different infrastructure, or move their account, to their own hosting even if they want.
Mastodon requires a complex decision upfront, which server do I trust, which is analogous to where you create your account on ATProto, but unlike ATProto, doesn't give the tools to seamlessly transition later.
The trust lens I think is a good one. You want to let different users make different tradeoffs in effort without having that leading to a worse experience..
I mean, this might depend on who your intended audience is? As perhaps pie-in-the-sky my desire is, I'd like to see one of these things replace twitter (as opposed to smaller communities.)
And it seems to me that the more frictionless model is the one that looks like something people are used to; just "sign up with a thing."
That does leave the interconnection to the servers and others, but that may be how it has to be?
"Sign up with a thing" -- but then what about after that? You've made a bunch of stuff, what happens to it?
Offloading THAT mentally to a different "service" or "account" I think is easier than this all-in-one thing.
Again, I like the IDEA a lot; if you'd presented it to me like in 2000 before a lot of this stuff took off I would have been all about it.
Today? No, I think it's reasonable to offload that to so-and-so-dot-com, each as a separate account. Like the phrase "I have a facebook" always sounds weird to ME, but I think that's "the way."
tl;dr: people have a huge diversity of preferences for social media, we need to rearchitect social networks to allow them to express those preferences while still connecting with each other, I think atproto enables this and is where I'm betting on.
Agh, sorry about this! I'm one of the people building leaflet.pub, which this blog is running on. Just pushed a fix for this (ironically on nextjs/vercel). The redirect loop is to handle sharing auth between our "main" domain, and people's various custom subdomains. Auth, via the ATProtocol, is used for things like subscribing and commenting!
disclosure: building a substack competitor on atproto
I'm really excited for ATProto as a way to build applications that let you have the benefits of substack (a unified network, recommendations, social features like comments, etc) without the eventual path to lock in.
It's particularly exciting because the incentive is actually there to build an application this way. Whether Bluesky is growing or not, there are currently 30M accounts that you can reach (with one of the best auth systems I've interacted with), AND atproto gives you the building blocks for others to build on your work. Both these things make the bootstrapping problem for any social application way down.
There's still a lot of stuff missing, payments being a big (and gnarly one), notification management being another, but both the bluesky team and the overall ecosystem has been moving at a solid pace, and things are getting more viable by the day.
Super early days, but we've been building a substack alternative on top of atproto, you can check out some publications people have made at leaflet.pub/discover.
I think atproto offers a pretty compelling way to get the benefits of substack, like discovery, native social features like comments, quotes etc, integration into a microblogging network; without locking into a closed network.
The extensibility story is also really good, opening interesting opportunities for individual publishers to augment their experiences.
Moderation, which is the main point of this article, is a bit of an open question, but diffusing responsibility the way bluesky does is a more promising direction imo than hoping a single trust and safety department can make everyone happy.
Not right now, self hosting isn't a priority for us at the moment. It shouldn't be tooooo difficult to figure out though, the two main infrastructure dependencies are supabase and nextjs and everything else is for additional features. I should make an example .env file to make all that clear though!
Leaflet looks like an amazing library. We only came across it and the naming collision after we got started, and so far haven't had too much confusion, but definitely a good idea to be aware when we do an SDK. Would love to make the confusion worse by including a map block in leaflet.pub via leafletjs someday though!
Unfortunately not yet, we haven't come up with a pattern we like for that yet, just added buttons quite recently. Right now the move is to delete and re-add, which I know is annoying. Will improve soon!
