We may be watching the emergence of a new "Web3" decentralized application stack.
Solid + Nostr + Client
This starts to map sensibly onto well-understood MVC or MVVM application patterns.
Discussion
Yes, the original web 3.0 when used correctly, and with nostr is actually the web done right.
What tech is on the client end of this stack? Native apps? PWAs? WebAssembly?
#asknostr
I don't think Pods are the answer. If they were Mastodon would be everything we wanted. But instead you get quasi locked into someone else's fiefdom.
Nostr has the same issue with relays. It isn't as bad since switching relays is easier, but unless you are running your own you are still at the mercy of someone else's whims.
Whatever comes next needs to be invariant from user to user. At least as invariant as it can be with our network layer. The only logical variation is public addressability under IP. (Blue-tooth mesh networks etc being actually invariant.)
Invariant does not mean equal. Some users will have greater storage, processing power, bandwidth, and faster pings to their contacts. Everyone, however, should own their own data and make their own connections.
The only reasonable definition of "own" is "hosts" but that term has baggage eliciting visions of configuring virtual private servers or docker containers, port forwarding on cheap routers, and all manner of nerdy headaches that only invite attacks.
But all it really means is that your data is physically saved on your devices and can be requested from you by authorized contacts. It doesn't fundementally need to be an active hobby.
Imagine a simplified case with a truly invariant mesh network. Everyone beams neutrinos directly to their personal contacts only. Getting a hold of anyone else would be 5 hops or less. Each user can save their own data to their device and merely notify some people that a reasource is available. Signed permission to request the data. Any unpermissioned request just gets dropped immediately by the first contact you ask to forward the request.
It is an automatic web-of-trust that isolates spam at the point of origin rather than the destination. This allows little people to host from the apps they use without getting overwhelmed.
But we don't have a magic p2p network with the IP protocol. Thus whatever is next isn't how do we give up and find more complicated server-client relationships that protect the clients. It needs to be how do we beat IP into a magic p2p network that works for everyone?
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.
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.
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!
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?
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!
Sounds very smart. I use git alot, which is a hash smaller than 32 bytes.
By the way. I didn't answer the main question! I am currently betting on webassembly with modified wasi extensions. That is actually the part I am coding now. I am making a VM service based on wasmtime so I can make cli applications that secretly run on the VM.
My biggest hesitation with WASM is that a compiled WASM application or library may be quite large. We can't rely on loading them every time a web page loads like we do with JS.
WASM libraries could perhaps be stored locally and only redownloaded when there are version updates, sort of like PWAs.
A WASM VM sounds promising! It would isolate code for security, but still run on the browser, correct?
No. I don't plan on incorporating a browser. The wasi extensions allow more native behavior.
A browser is, however, an application that could use the VM. It would gain access to signing services so logins become a thing of the past. Like oauth without the dependencies on large providers like Google and GitHub.
I'm working on nostr authentication using schnorr signatures too
Love it! This is the most obvious next step for browsers. I am not sure why it hasn't been pushed through by a big player. Probably because they are all oauth providers and the lock in is welcome.
Thanks! It's based on NIP-98 which I co-wrote with Kieran and is in wide use. Re big players, absolutely yes. They also want to couple everything to email. And the email providers are also the web giants.
This little shim will allow you to do an authenticated write operation, for example.
Ohh so it's a VM that runs WASM.
What is the advantage of that over other solutions, like native apps?
Yes. It is more of a service maintaining VPN like connections between peers, managing keys, handling signing and encryption, permissions etc. But it also hosts a VM so applications can easily get access to those services without having to even know about them. For instance if I had the code for a native C program that just needed file access, I could compile it to the wasmtime-wasi target and all the data it processed would be available on all my machines.
For applications that need to communicate with other people there could be a simple API that gets you a stream reader/writer and you wouldn't need to know anything about the p2p network.
I am also toying with ideas to just make the service expose a native API so native applications can access it as well. That is harder to sand box though. With WASM you can be slightly more careless about installing some game your friends are all playing as long as there are careful guards about what contexts you give it access to.
The long con is getting some VM wasm or something else, that has the ability to run different pieces on different machines so you can get distributed compute as well as distributed data. Imagine immediately getting full power of your gaming rig on your laptop or even phone, with 0 configuration. Also being able to move between machines and have your running applications follow you.
Then extend to mutual agreements with friends. So much untapped idle horsepower. Muwahaha!!
Yes. I plan on storing them on my distributed file system, just a binary blob like everything else. We don't want a client server kind of thing. You "install" an application by signing a small notification sent by others in your network that is basically a little description card.
"App: HelloWord, Context:{cli_write}, ID:Som3H4sh, DecryptionKey:50meK3y"
You sign that and your VM creates keys needed for the contexts the the app needs access to. Then anywhere you try to run that program it downloads it and runs it. Keeping the binary local there after.