Oddbean new post about login | logout I want to make pubky so good that no indiehacker can be bothered setting up a backend to validate an idea. They would tell early adoptors; Just sign in with your pubky and come with your own backend, and that wouldn't be too much to ask. Maybe even attractive to users who know that their data won't disappear if the developer got distracted by another side project.
I love this project and I hope will succeed. I am thinking to bring yggdrasil in the mix. That network works pretty great and the fact you can generate your own IPv6 from ed25519 keys is awesome. With these two you can setup a network however you want. Ygg is giving the metwork, pubky the dns and resolve. At this point you don't even need k8s, goes with out saying cloud monopol can finally be teard down. There are tones of applications, you can do anything. From end user apps to low level such as db, file storage. All is possible now :)
I am aware of Yggdrassil and I tried it myself, works well. I don't have any specific plans to use it, but I think Pkarr can help Yggdrassil, and I would be happy to help the Yggdrassil team or anyone who wants to hack them together. We already can use upnp or hole punching to run servers from anywhere, but Pkarr is not suited for records that change often (caching and TTL is important for scaling) so anything that allows servers to have stable endpoints is welcome.
wasn't that the idea of remotestorage too?
Pubky is definitely inspired by RemoteStorage and the general Unhosted.org philosophy. I believe we do things that RemoteStorage does not do though. Most importantly; Pkarr instead of web fingers, and the paginated listing API making Pubky an ordered key value store, not just a filesystem.
how do you envision it happening? like how are users going to authenticate from a random webapp in order to read or write to their backend?
we are further ahead from vision, we have an e2e example in pubky-core repo. And it is all specced out here https://pubky.github.io/pubky-core/spec/auth.html Long story short; the web app asks the user for specific capabilities, the user approves by sending a signed token to the web app (using httprelay.io) then that web app uses this signed token to sign in to the user homeserver and get a good old session cookie with only the capabilities that the user approved
Webfinger was by far the weakest part in the stack. So many mistakes like spinning up a new URI scheme, inventing a new JSON format, and moving away from its original use case.
FWIW the inventor of unhosted/remotestorage, now works on Solid. I remember going to the first unhosted meetups over 10 years ago, and still know one of the team. But after a decade it's yet to take off in a major way, and newer solutions have come along.