This is the best in-depth dive in to how bluesky works from a code / infrastructure perspective that I’ve seen. I think anybody trying to understand and build Nostr should take a look. In a ton of ways atproto and nostr are siblings in how they work. It’s all the same stuff but slightly tweaked and in different proportions.
We have relays, they have relays. Their events are defined by signatures of the event and so our ours. They’ve got some differences, Nostr does casual ordering by timestamp whereas they’ve got a kind of merkel tree as part of the event. Their clients talk to a PDS server which holds keys similar to nsec bunker, but it also acts as a personal relay, which we have but not everybody uses. Our labelers are any nostr user or bot, whereas theirs a specific cloud service middleware. We’ve got DVM’s and other middleware which can generate custom feeds, but it’s not needed, clients can do their own thing or decide sorting. Whereas custom feeds in atproto are more core and extensible.
They plan to add payments and a DVM type service, but haven’t gotten to that yet, where as we have zaps already.
Because of the way bluesky has control over who can connect to their relay and submit data to their servers, users on the main bluesky network have to receive their content with their moderate bot labels via both AI and the Ozone app.
Bluesky supports arbitrary datastructures and lots of kinds of apps beyond the twitter like microblogging, but as far as I know nobody’s built one. Where as Nostr has tons of weird interesting apps.
https://newsletter.pragmaticengineer.com/p/bluesky
https://arxiv.org/pdf/2402.03239.pdf
Rabble /
npub1wm…jg240
2024-04-25 03:24:02
Author Public Key
npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240Published at
2024-04-25 03:24:02Event JSON
{
"id": "2074aba90c4907d97d0863f3ef0fb5c134d933b61f421df031ed84b4b384e026",
"pubkey": "76c71aae3a491f1d9eec47cba17e229cda4113a0bbb6e6ae1776d7643e29cafa",
"created_at": 1714008242,
"kind": 1,
"tags": [],
"content": "This is the best in-depth dive in to how bluesky works from a code / infrastructure perspective that I’ve seen. I think anybody trying to understand and build Nostr should take a look. In a ton of ways atproto and nostr are siblings in how they work. It’s all the same stuff but slightly tweaked and in different proportions. \n\nWe have relays, they have relays. Their events are defined by signatures of the event and so our ours. They’ve got some differences, Nostr does casual ordering by timestamp whereas they’ve got a kind of merkel tree as part of the event. Their clients talk to a PDS server which holds keys similar to nsec bunker, but it also acts as a personal relay, which we have but not everybody uses. Our labelers are any nostr user or bot, whereas theirs a specific cloud service middleware. We’ve got DVM’s and other middleware which can generate custom feeds, but it’s not needed, clients can do their own thing or decide sorting. Whereas custom feeds in atproto are more core and extensible. \n\nThey plan to add payments and a DVM type service, but haven’t gotten to that yet, where as we have zaps already. \n\nBecause of the way bluesky has control over who can connect to their relay and submit data to their servers, users on the main bluesky network have to receive their content with their moderate bot labels via both AI and the Ozone app. \n\nBluesky supports arbitrary datastructures and lots of kinds of apps beyond the twitter like microblogging, but as far as I know nobody’s built one. Where as Nostr has tons of weird interesting apps. \n\nhttps://newsletter.pragmaticengineer.com/p/bluesky\n\nhttps://arxiv.org/pdf/2402.03239.pdf",
"sig": "4ed1ceb82085e72ca6f363d5017c8a52a51005a5610eeb3932eb62bcd9f9a534a565bb9b8813dfdd57312554f0e64e95c79225f82b9bb6ec1a8ecdd439ded2b8"
}