191–200 of 243 posts
Why would we need to store the createdAt value in a file? The filesystem already stores this information. We could just store the text which would mean no Json would be needed.
The important parallel I was going for was "file format" as interface between apps (= lexicons being an interface between social apps).
If you want details on the actual data structures, check https://atproto.com/specs/repository.
Earlier quoted context omitted.
That's a great question! Adding new features is usually not a problem because you can always add optional fields and extend open unions. So, you just change `media: Link | Picture | unknown` to `media: Link | Picture | Video | unknown`. You can't remove things true, so records do get some deprecated fields. Re: updating safely, the rule is that you can't change which records it would consider valid after it gets used…
That's true if you define the problem as "does my parser crash" and not whether the app is perceived as working correctly. If some platform adds support for video posts, then the next thing that happens is people start making posts that are only video. Meaning that in every other client, users see what appears to be an entirely empty post. Which will be considered a bug. This is the core argument of Moxie's seminal e…
I've actually observed the exact opposite thing. Since Bluesky is open source, it's often visible when developers start working on a feature. And they often check in lexicon changes early on. As a result, there's been a few cases where third party client actually added support for these features earlier than the official one since they already knew the shape of the data.
This wouldn't always work, of course. Yes, if you're developing an app or a client, you better keep up with the ecosystem. But the landscape is competitive and there is no cost to switching. So if something falls behind, you can use something else.
I like the write-up of this idea. It's well presented. But I'd change one aspect: "We could leave author: 'dril' in the JSON but this is unnecessary too." - kind of. What the post lacks is the record of the identity at the time. What the user's username and the avatar was at the time can change the meaning of the post entirely. To really preserve the message, you need to reference what the displayed identity was used…
That said, you could create an AT app that displays a version of the post using the profile at the time. You'd just need to index all profile changes into a local database, and then query that database for the "profile at that time" to display the post. So what you're describing is possible—it just requires a different aggregation. The source of truth, however, should be denormalized and reflect most recent data.
Earlier quoted context omitted.
Tangled founder here; it's just as easy! For example, here's the entire Tangled codebase monorepo: https://tangled.org/tangled.org/core — you can clone this directly as you would a git repo anywhere else.
Looks nice! New user sign up is a bit wonky. It asked for an email, login and password, then it's asking for a bsky sign-in too? This seems a little weird. (Minor nit: for some reason, Google didn't auto-suggest a strong password for the password field.) Then I got to the screen where it asks for full read-write access to my PDS and stopped there. It's kind of a lot to ask! I believe this is Bluesky's fault, but I do…
Earlier quoted context omitted.
I mean, I can literally already self-host my personal data if I want to. And there are also already forks of Bluesky (not just the client, but the server and the database ) that can participate without fragmenting the network. It is not a perfect system but it's so far from where you are when you just rely on a closed app.
That's great, but also Mastodon is just there and has been for quite some time. I see no added value in Bluesky/ATProto beyond the layer of that "social as a service" which looks like a walled garden / app store of sorts in the making. I may be wrong, of course...
Mastodon is just a bunch of isolated copies of the same app talking to each other. There is no notion of a shared identity, each server's admin is effectively a king over your account, etc. It's a fragmented patchwork of isolated sites that forward messages.
With AT, there is just one global network. Like the web. You don't post "to" someone's isolated copy of an app. You post to your own folder, and every interested app can aggregate your post.
It's a bit like email vs RSS. Very different shapes.
To give you a concrete example to ground it. Blacksky is a fork of Bluesky. They're setting up their own server with different moderation policies and are unbanning some people that Bluesky has banned (https://bsky.app/profile/rude1.blacksky.team/post/3mcozwdhjo...). However, Blacksky posts still exist in the same "world" as Bluesky--they are not an isolated fragment.
Thanks to AT, Blacksky and Bluesky are just two different prisms through which you see a single network. Whereas with Mastodon, every app is its own network, with some limited message passing between them.
How does this system determine the amount of likes a post has? Since there is no back reference on a post to people who have liked it, don't you have to iterate over every single person, iterate over their likes, to see if one of them is the post you are viewing, and add all them up?
How does this system determine the amount of likes a post has? Since there is no back reference on a post to people who have liked it, don't you have to iterate over every single person, iterate over their likes, to see if one of them is the post you are viewing, and add all them up?
In the ATProto architecture, this function is handled by the AppView, which monitors the full network and produces the corresponding aggregates.
It's basically event sourcing. You listen to the data you care about from the network and update the local index (DB). There are also tools like Tap (https://docs.bsky.app/blog/introducing-tap) that do the plumbing work and let you backfill automatically.
Earlier quoted context omitted.
In the ATProto architecture, this function is handled by the AppView, which monitors the full network and produces the corresponding aggregates.
Yes. I describe this in this part of the article: https://overreacted.io/a-social-filesystem/#:~:text=One%20ch... It's basically event sourcing. You listen to the data you care about from the network and update the local index (DB). There are also tools like Tap ( https://docs.bsky.app/blog/introducing-tap ) that do the plumbing work and let you backfill automatically.
I've seen a few people make other ones when examining their accounts with pdsls, but they seem to be there for "just because I can" reasons.
Earlier quoted context omitted.
That's great, but also Mastodon is just there and has been for quite some time. I see no added value in Bluesky/ATProto beyond the layer of that "social as a service" which looks like a walled garden / app store of sorts in the making. I may be wrong, of course...
Mastodon isn't doing anything similar! Mastodon is just a bunch of isolated copies of the same app talking to each other. There is no notion of a shared identity, each server's admin is effectively a king over your account, etc. It's a fragmented patchwork of isolated sites that forward messages. With AT, there is just one global network. Like the web. You don't post "to" someone's isolated copy of an app. You post t…
There is no pre-existing need or desire for people to put all their data into a single space - that part is entirely driven by social companies themselves which of course benefit from that kind of centralisation and interoperability. So yes, the prism is that our social interactions become a data product and more - a data product "under governance", well structured and with well defined schema, etc.
For end users, functionally, there is very little to be gained (and some things to be let go) but the technology is not accessible enough for non-tech folks to decide on the tradeoff themselves.
As for Mastodon, what you call limited currently includes editing posts, long form posts and private blocklists (among others), all features Bluesky lacks and current version of atproto does not allow. So let's not try to quantify/compare them like that.
Regardless, I like the idea overall, I believe the Solid project (https://solidproject.org/) addresses a similar concept but when less dependence on a single authority as is the case of Bluesky and ATProto.