Decentralizing Schemes

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.

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.

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.