Subnostr

Mastodon doesnt use pods. Which is kind of a shame, because they implemented part of the standard, but not the bit that lets them have pods.

From my POV all the things you say can be done with an "AND" attitude. The prevailing attitude is "OR". We use Nostr OR we use Solid. We use BlueSky OR we use Mastodon.

The OR mentality is great for developers and empire builders. The AND mentality is great for users. I've always thought from a user perspective of building the things I want to use myself. It's a minority view, and you actually get a lot of hate when you have a user perspective. But in the end you get to use a good system, and as a side-effect others do too.

A better solution is "AND". We use nostr npubs AND we use nip-05 addresses. Same with having Nostr to relay and Pods or DBs for storage. Nostr is one of the worst imaginable DBs, but has great properties as a relay.

So the "AND" mentality works really well. Of course few want to admit this, because then they cant say "Nostr fixes this", and all the money that goes with that.

Pods are simply a piece of the internet under your control. Much like a unix file system. It could be on your phone, in the cloud, or on your file system. The glue is in place to include all of this, plus have privacy controls. AND mentality is 100x more powerful than OR. Simply look at what Zuckerberg built in 2 weeks with the LAMP stack. He needed all 4 things for it. Any one on it's would not have been enough.

Daniel Wigton 1y ago

I might be misunderstanding the Solid protocol (Very likely). Also I mixed up Mastodon and Diaspora. In both cases, however, you are beholden to whoever runs your instance.

I agree, however, that we need a both strategy. I wouldn't get rid of the whole messy TLS/HTTP/TCP/IP + DNS stack. It is a nice way to authenticate and access widely available services. But it is a nightmare of lock in and for identity and personal data. I think we can use the current paradigm to bootstrap something that looks like a magic p2p network.

So, like you suggested, that is exactly what I am building for myself. It doesn't use Nostr and Solid, because I think they have missed the mark. I am probably wrong, but I have the ability if not so much the time, to give it a try.

The worst outcome will be that I end up with a unique way to sync my personal data across my computers at home that no one else uses.

Reply to this note

Please Login to reply.

Discussion

Melvin Carvalho 1y ago

This is very good. So the thing is. If you are able to think creatively and take the BOTH strategy. You can, say, have a nostr key, and an HTTP key, in a COMBINED profile. This allows migration more easily. Just like chaning NIP-05 is easy. Frankly even nostr migration is still terrible. Profiles break all the time between relays. As mine is now. The trick is dont lock yourself into any one solution and take the advantages of all. The Nostr people dont want to talk to activitypub (apart from alex). And the activitypub people dont want to talk to Nostr. But for an end user, having everything is by far the best option. And they dont even need to know the technology behind it. Looking forward to see what you make!

Melvin Carvalho 1y ago

Agree both Solid and Nostr have missed the mark, to a degree. You just want to take the good parts. That is what I will do.

What are you going to use for sync?

Daniel Wigton 1y ago

Because of the way I am handling communication all files exist as serialized->compressed->encrypted blob identified only by it's blake3 hash. Any info about them is handled by Notifications. Those are single packets of data saying what they are and signing permission to access.

The first use case will be simply communicating with myself. My computers will share notifications of what is available and they can decide whether to transfer the files between them right away or wait till wanted. I'll have to look at caching algorithms to fine-tune where things get stored. I can't just sync and deduplicate since devices may have differing storage capabilities and I'll have to pick what level of redundancy I want. It is very much a work in progress.

At least storing everything with its hash will make deduplication easy. I am just hoping I can get away with fewer than 32 bytes. I have to carefully revisit the security implications. Anything I can save on hash size is a performance win. Premature optimization ftw!

Melvin Carvalho 1y ago

Sounds very smart. I use git alot, which is a hash smaller than 32 bytes.