Pubky core is like Nip01, it is like DNS and WebDav, and it is more or less what I just described.

Now you can build on top of such stack, I am sure you could come up with 100s of micro apps ideas. Others will too. Your data (the public parts) will be available to them and theirs to you. If you also want every developer to interop with others, get them in a room I guess. Pubky core is not any more responsible for that than the spec of Websocket is responsible for Nostr clients understanding each other.

There is no magic for interoperability, and I don't personally consider it my mission, I want censorship resistant DNS, and a data store with an open API. Higher level abstractions will churn like hell, but at least the data will be there for anyone motivated enough to reverse engineer it and squeeze some value from it.

Reply to this note

Please Login to reply.

Discussion

I am never going to build on top of a stack that I cannot understand to its core. And never going to build in a "decentralized" stack that is fully centralized in just one code base.

I am not saying that apps that use pubky must get together. I am saying that multiple (hundreds) implementers of the protocol behind pubky need to exist.

Otherwise, this is not decentralized at all.

This is no censorship resistance if we are all using the same code.

> Now you can build on top of such stack, I am sure you could come up with 100s of micro apps ideas

Will each app just put their data in a subdirectory of a user? If so, that reminds me a lot of GunDB! nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk

depends on what they are doing and what paths are users giving them access to, but there is no enforcement of sandboxing like in say IOS or something.

Is there a concept of giving access only to specific files / directories then?