I am surprised that the comments on that blog don’t menstion Nostr as a solution to the given pain points.
Unlike traditional federated systems, Nostr is built around a protocol where users have a single cryptographic identity not tied to any particular server. This means that when a user shares a post, anyone with a Nostr client can interact with it—like, comment, or repost—regardless of which relay (server) they are connected to, solving the “can’t interact across instances” problem.
Moreover, Nostr posts are identified by content hashes and public keys, not by server-dependent URLs. This makes posts portable and resilient: if a relay goes offline or a user migrates, their content and identity remain intact and accessible via other relays, addressing the “post portability pain” and “migration pain” described in the article.
And because Nostr clients can register themselves as handlers for Nostr-specific links (e.g., nostr: URIs), clicking a Nostr link can automatically open the post in the user’s preferred client, improving the user experience across different devices and apps.
I read your post after posting my own. Yeah the lack of any mention of Nostr shows a genuine ignorance about the Social Media Protocol landscape or else an intentional dislike of Nostr, and thus not wanting to do any shout-outs.
Nostr isn't something special. It's just currently in the phase where we dream about the possibilities and don't have enough practical experience to see the problems yet, and ignore the theoretical problems because we haven't encountered them in reality yet. Fediverse also went through that phase. So did centralized social media.
Nostr has 1) Identity as a PublicKey, 2) Posts represented as hashes. That's all we need. The mechanism for pushing those chunks of data around the web is almost irrelevant. Nostr uses relays. IPFS uses a DHT. The possibilities are endless, but Nostr is special because it has [mostly] exactly what we need at it's core, and makes every other feature optional. I invented something identical to Nostr several months before Fiatjaf did, and I think he may have actually gotten many ideas from me, just like I contributed very heavily towards the Blue Sky effort, and got them to accept most of my ideas. The "Personal Repository" concept was mine for example. I invented that.
Neither of which is anything new, and neither of which helps you actually get the content. You have to have the whole system or you don't have a system.
IPFS's DHT is extremely slow by the way - on the order of 1-10 minutes to look up a new item. That's one of those things about it that the people who insist it's the solution to all problems won't tell you. I assume there's some such problem with nostr too (probably not the same one). Every system has them.
Has nostr experienced a takedown, crash, corporate takeover, or overload of one or several major relays yet, and if so, how did that go? Did enough users find out about the problem through out-of-band channels, then manually enter new relay URLs, to keep the network mostly connected? Has anyone important had their private key stolen?
The version of Nostr that I happened to invent about a year before Fiatjaf invented his was about the same as Nostr, except for the fact that I chose a true IPFS CID as the identifier, which Nostr cannot do, making it completely incompatible with IPFS, unless you have TWO hashes (both a CID and a Nostr ID), which I found silly.
You're right about the fact that IPFS never could scale to the level of Social Media with everyone posting even 10 messages per day, but decentralized systems NEVER DO scale in that way. That's why Blockchain has Lightning as you know.
However inventing a NEW CID format in the IPFS era is a foot shoot, that can be avoided, and should be. Can the other problem (of how to push data efficiently) ever be solved perfectly? Maybe or maybe not, but Nostr does work, and it is censorship resistant better than anything else. I'm just saying what a shame that it's wholly separate from IPFS. That was a huge lost opportunity. And I generally disagree with your gripe that everything is worthless until everything is perfect, because by that logic even Public Key encryption is a baby to be thrown right out with the bath water too. No, the overall system will be made of parts. The CID part is a necessary part, and the PublicKey identity is also a necessary part.
From the fact that you completely ignored the question on whether Nostr has suffered a reality-injecting major problem yet, I assume that it hasn't yet.
BTW IPFS CID isn't even the best, oldest or most stable identifier. We had SHA256 hashes before IPFS.
I answer about things I'm interested in and know about. I don't know about any breaches of Nostr protocol, because I quit all Nostr work 2 years ago.
About IFPS hashing... I'm a very experienced IFPS developer myself (2 years of it). I always argued the 'variable hash algorithm' aspect of IPFS was just an unnecessary complexity and that SHA256 should've been hard-coded into the whole thing. As per usual, the IPFS team went with the more complex approach, just like they did when they over-engineered ATProto in the same way by the SAME developer.
But the main reason Nostr cannot fit into IPFS is slightly more nuanced than the actual hash algo. Fiatjaf made the decision NOT to take the hash of the FINAL JSON object itself, and so no matter what hash algo he had used, it was never going to cleanly fit into IPFS without each Nostr message being 'wrapped' with some IPFS wrapper, necessarily resulting in an DIFFERENT hash. So there's two different layers to the incompatableness.
EDIT: Going deeper into the weeds: If social media messages are shorter than 256K (the default chunker size of IPFS) I think you can end up getting a SHA256 directly out of it, so there WAS the potential to use IPFS with Nostr in that way, except for the fact that Fiatjaf didn't hash the FINAL JSON, but hashed parts of it.
Hey Fraze! I'm a big fan of yours! I bet you know who I am, but don't dox me plz. :) I hope things are going well for you at Blue Sky actually, if you're still there. I think all your contributions to ATProto were probably all the good ones!
I remember Jeromy and his boss Cake who pretended to interview me for a job once, which cratered when I refused to do the "coding challenge" purely out of the principle of the thing. lol.
> Whatever I think of whoever’s running mastodon.cloud, I have a lot of posts over there, some of which I care about. For now, they’re still there, but I’m not contributing any money to those guys, nor will I, so if they pull the plug and vanish I can’t complain. Only if they do, so do all those posts that I cared about back then and still do a bit.
"Nor will I" seems a bit strong here. This pain point seems rather self-inflicted, is it not? You get what you pay for and the ownership model of the Fediverse is you help pay for your instance (or instances). If you want ownership of your posts, become an owner of your instance.
That's one of the big reasons why I trust the Fediverse a lot more than AtProto. BlueSky is VC funded and the ownership model is hard to define and the business model is "ads now, maybe worse ads tomorrow". With the Fediverse I can own my instance like I can (and do) own my blog. I myself am not an ad company and I don't have to worry about future me injecting increasingly worse ads into my instance (and I'm free to block and defederate instances that think spam is a good idea).
You get what you pay for, and I'm happier to pay for a tiny corner of the Fediverse than try to be a sharecropper in AtProto with the possibility that Maybe Someday TM it will be distributed enough to matter (to avoid BlueSky's business model).
When I was working on the Fluid Framework, now basically Microsoft's Copilot Pages, we built a URI Schema to let in-app widgets specify the code that would let users interact with the underlying data.
Example: you open the app and load a specific document. Simplified, but this loads a "boot loader" and connects to the data feed of the document. The boot loader reads the first few operations which contains the widget/app code to load all the UX of the application. Examples of widgets would be a whiteboard, a text editor, a table widget, an identity card, a latex widget, etc.
Widgets could be posted outside of the document because any loader that could read the URI could parse it and understand the app code to load and data feed to connect to.
I'm still somewhat infatuated with the design and I'd like to see it much more widely adopted. Security issues were, of course, a major issue.
They used to be decentralized. I remember a game making platform called BYOND. The website had a list of games. If you clicked on a button to play one, it pointed to a URL like byond://Author.Game?server=1.2.3.4 and if you had the BYOND software installed, it would open. And this wasn't just what BYOND did - it was just what apps were expected to do in order to integrate with the web. I suppose it went away when the apps could run inside the browser instead of being launched outside it.
Nostr solves the identity problem, and IPFS solves the data sharing problem.
Unfortunately the guy who created Nostr wasn't an IPFS fan, and the IPFS guys who played the key role in developing Blue Sky weren't fans of simplicity like the Nostr dude was. So we ended up with a mess, where there could've been a big synergy.
And to make matters even worse everyone in the ActivityPub world (i.e. Fediverse, Mastodon,et all) is of the opinion that having a DNS name embedded into Usernames is congruent with freedom of movement and censorship resistance, even though it's not.
In fact, most of the Fediverse is full of super-woke types who love censorship as much as antifa loves the color black, so they're a hopeless cause as well. So once again, what a mess.
We were so so close. I mean even one slight tweak of how the Nostr Hash is generated COULD HAVE made it's message hashes genuine IPFS CIDs and made everything perfectly interoperable. No one to this day has gotten it right yet, but we're close.
bluesky will never be federated. it's nothing but twitter2. the federation stuff is just marketing, like nestle saying whatever they sell is homemade like.
Yeah Blue Sky is run by people (like Jay Graber, a hard-core leftist) who secretly want to keep Blue Sky centralized, and only pretend it's Federated, to get the ActivityPub devs to jump ship and to go ATProto. You're right. They got corrupted by power and politics. Nostr is much better and simpler, although it's lead developer is quite childish and I found him quite intolerable as a human.
I always had argued if Bitcoin somehow works without key rotation then so can Social Media. And if someone can steal your key, they can also "rotate it" out from under you too, so it's just wasted effort.
As for getting all devices to work, entering a 66 byte hex key into each device is totally fine imo too. I mean, you can even let people generate their Private Key from a Password string if ya want.
Nostr isn't flawed in those two ways. It's KISS in those two ways.
I am surprised that the comments on that blog don’t menstion Nostr as a solution to the given pain points.
Unlike traditional federated systems, Nostr is built around a protocol where users have a single cryptographic identity not tied to any particular server. This means that when a user shares a post, anyone with a Nostr client can interact with it—like, comment, or repost—regardless of which relay (server) they are connected to, solving the “can’t interact across instances” problem.
Moreover, Nostr posts are identified by content hashes and public keys, not by server-dependent URLs. This makes posts portable and resilient: if a relay goes offline or a user migrates, their content and identity remain intact and accessible via other relays, addressing the “post portability pain” and “migration pain” described in the article.
And because Nostr clients can register themselves as handlers for Nostr-specific links (e.g., nostr: URIs), clicking a Nostr link can automatically open the post in the user’s preferred client, improving the user experience across different devices and apps.
I read your post after posting my own. Yeah the lack of any mention of Nostr shows a genuine ignorance about the Social Media Protocol landscape or else an intentional dislike of Nostr, and thus not wanting to do any shout-outs.
Nostr isn't something special. It's just currently in the phase where we dream about the possibilities and don't have enough practical experience to see the problems yet, and ignore the theoretical problems because we haven't encountered them in reality yet. Fediverse also went through that phase. So did centralized social media.
Nostr has 1) Identity as a PublicKey, 2) Posts represented as hashes. That's all we need. The mechanism for pushing those chunks of data around the web is almost irrelevant. Nostr uses relays. IPFS uses a DHT. The possibilities are endless, but Nostr is special because it has [mostly] exactly what we need at it's core, and makes every other feature optional. I invented something identical to Nostr several months before Fiatjaf did, and I think he may have actually gotten many ideas from me, just like I contributed very heavily towards the Blue Sky effort, and got them to accept most of my ideas. The "Personal Repository" concept was mine for example. I invented that.
Neither of which is anything new, and neither of which helps you actually get the content. You have to have the whole system or you don't have a system.
IPFS's DHT is extremely slow by the way - on the order of 1-10 minutes to look up a new item. That's one of those things about it that the people who insist it's the solution to all problems won't tell you. I assume there's some such problem with nostr too (probably not the same one). Every system has them.
Has nostr experienced a takedown, crash, corporate takeover, or overload of one or several major relays yet, and if so, how did that go? Did enough users find out about the problem through out-of-band channels, then manually enter new relay URLs, to keep the network mostly connected? Has anyone important had their private key stolen?
The version of Nostr that I happened to invent about a year before Fiatjaf invented his was about the same as Nostr, except for the fact that I chose a true IPFS CID as the identifier, which Nostr cannot do, making it completely incompatible with IPFS, unless you have TWO hashes (both a CID and a Nostr ID), which I found silly.
You're right about the fact that IPFS never could scale to the level of Social Media with everyone posting even 10 messages per day, but decentralized systems NEVER DO scale in that way. That's why Blockchain has Lightning as you know.
However inventing a NEW CID format in the IPFS era is a foot shoot, that can be avoided, and should be. Can the other problem (of how to push data efficiently) ever be solved perfectly? Maybe or maybe not, but Nostr does work, and it is censorship resistant better than anything else. I'm just saying what a shame that it's wholly separate from IPFS. That was a huge lost opportunity. And I generally disagree with your gripe that everything is worthless until everything is perfect, because by that logic even Public Key encryption is a baby to be thrown right out with the bath water too. No, the overall system will be made of parts. The CID part is a necessary part, and the PublicKey identity is also a necessary part.
From the fact that you completely ignored the question on whether Nostr has suffered a reality-injecting major problem yet, I assume that it hasn't yet.
BTW IPFS CID isn't even the best, oldest or most stable identifier. We had SHA256 hashes before IPFS.
I answer about things I'm interested in and know about. I don't know about any breaches of Nostr protocol, because I quit all Nostr work 2 years ago.
About IFPS hashing... I'm a very experienced IFPS developer myself (2 years of it). I always argued the 'variable hash algorithm' aspect of IPFS was just an unnecessary complexity and that SHA256 should've been hard-coded into the whole thing. As per usual, the IPFS team went with the more complex approach, just like they did when they over-engineered ATProto in the same way by the SAME developer.
But the main reason Nostr cannot fit into IPFS is slightly more nuanced than the actual hash algo. Fiatjaf made the decision NOT to take the hash of the FINAL JSON object itself, and so no matter what hash algo he had used, it was never going to cleanly fit into IPFS without each Nostr message being 'wrapped' with some IPFS wrapper, necessarily resulting in an DIFFERENT hash. So there's two different layers to the incompatableness.
EDIT: Going deeper into the weeds: If social media messages are shorter than 256K (the default chunker size of IPFS) I think you can end up getting a SHA256 directly out of it, so there WAS the potential to use IPFS with Nostr in that way, except for the fact that Fiatjaf didn't hash the FINAL JSON, but hashed parts of it.
Holmgren and I overengineered atproto without jeromy's help
Hey Fraze! I'm a big fan of yours! I bet you know who I am, but don't dox me plz. :) I hope things are going well for you at Blue Sky actually, if you're still there. I think all your contributions to ATProto were probably all the good ones!
I remember Jeromy and his boss Cake who pretended to interview me for a job once, which cratered when I refused to do the "coding challenge" purely out of the principle of the thing. lol.
> Whatever I think of whoever’s running mastodon.cloud, I have a lot of posts over there, some of which I care about. For now, they’re still there, but I’m not contributing any money to those guys, nor will I, so if they pull the plug and vanish I can’t complain. Only if they do, so do all those posts that I cared about back then and still do a bit.
"Nor will I" seems a bit strong here. This pain point seems rather self-inflicted, is it not? You get what you pay for and the ownership model of the Fediverse is you help pay for your instance (or instances). If you want ownership of your posts, become an owner of your instance.
That's one of the big reasons why I trust the Fediverse a lot more than AtProto. BlueSky is VC funded and the ownership model is hard to define and the business model is "ads now, maybe worse ads tomorrow". With the Fediverse I can own my instance like I can (and do) own my blog. I myself am not an ad company and I don't have to worry about future me injecting increasingly worse ads into my instance (and I'm free to block and defederate instances that think spam is a good idea).
You get what you pay for, and I'm happier to pay for a tiny corner of the Fediverse than try to be a sharecropper in AtProto with the possibility that Maybe Someday TM it will be distributed enough to matter (to avoid BlueSky's business model).
When I was working on the Fluid Framework, now basically Microsoft's Copilot Pages, we built a URI Schema to let in-app widgets specify the code that would let users interact with the underlying data.
Example: you open the app and load a specific document. Simplified, but this loads a "boot loader" and connects to the data feed of the document. The boot loader reads the first few operations which contains the widget/app code to load all the UX of the application. Examples of widgets would be a whiteboard, a text editor, a table widget, an identity card, a latex widget, etc.
Widgets could be posted outside of the document because any loader that could read the URI could parse it and understand the app code to load and data feed to connect to.
I'm still somewhat infatuated with the design and I'd like to see it much more widely adopted. Security issues were, of course, a major issue.
They used to be decentralized. I remember a game making platform called BYOND. The website had a list of games. If you clicked on a button to play one, it pointed to a URL like byond://Author.Game?server=1.2.3.4 and if you had the BYOND software installed, it would open. And this wasn't just what BYOND did - it was just what apps were expected to do in order to integrate with the web. I suppose it went away when the apps could run inside the browser instead of being launched outside it.
Nostr solves the identity problem, and IPFS solves the data sharing problem.
Unfortunately the guy who created Nostr wasn't an IPFS fan, and the IPFS guys who played the key role in developing Blue Sky weren't fans of simplicity like the Nostr dude was. So we ended up with a mess, where there could've been a big synergy.
And to make matters even worse everyone in the ActivityPub world (i.e. Fediverse, Mastodon,et all) is of the opinion that having a DNS name embedded into Usernames is congruent with freedom of movement and censorship resistance, even though it's not.
In fact, most of the Fediverse is full of super-woke types who love censorship as much as antifa loves the color black, so they're a hopeless cause as well. So once again, what a mess.
We were so so close. I mean even one slight tweak of how the Nostr Hash is generated COULD HAVE made it's message hashes genuine IPFS CIDs and made everything perfectly interoperable. No one to this day has gotten it right yet, but we're close.
bluesky will never be federated. it's nothing but twitter2. the federation stuff is just marketing, like nestle saying whatever they sell is homemade like.
Yeah Blue Sky is run by people (like Jay Graber, a hard-core leftist) who secretly want to keep Blue Sky centralized, and only pretend it's Federated, to get the ActivityPub devs to jump ship and to go ATProto. You're right. They got corrupted by power and politics. Nostr is much better and simpler, although it's lead developer is quite childish and I found him quite intolerable as a human.
how's nostr doing with multiple devices or key rotation?
I always had argued if Bitcoin somehow works without key rotation then so can Social Media. And if someone can steal your key, they can also "rotate it" out from under you too, so it's just wasted effort.
As for getting all devices to work, entering a 66 byte hex key into each device is totally fine imo too. I mean, you can even let people generate their Private Key from a Password string if ya want.
Nostr isn't flawed in those two ways. It's KISS in those two ways.