Pubky uses a homeserver model, which is chosen by the key holder. (Via PKDNS).

To bootstrap the network, we are of course providing a free homeserver, so people can post in the app.

That means, like with relays, spammers can infinitely make accounts and use diskspace.

...but we arent ready for that, or for scale, we are still in beta!

So, instead of charging fees or asking for SMS, or Gmail, Bluesky or others, we are regulating the flow with invite codes until we, and the code, is ready for primetime.

In the end, people will be able to host themselves, or choose any host provider as homeserver, all while still controlling their own discovery via pkdns/pkarr. That just is not very easy yet.

So, the codes help me regulate flow into the beta, and prevent spam before we have ways to mitigate it. Nothing nefarious!

Reply to this note

Please Login to reply.

Discussion

Btw you would love playing with our Nexus indexer graph, it includes keys, URLs, connected by tags, all indexed and ready to query and create powerful, and contextual!, WoT views.

It's available for users?

As so its to prevent spamming, makes sense.

Once there are other home servers and user A follows user B on another server how will user A get users B content? is the idea to use a similar approach as activity pub where the servers have to federate. or is it on the users to fetch the content from the other server?

In the context of our flagship Pubky app, we use and provide an indexer, which aggregates all related data in the app environment. (Right now it only checks our homeserver, later, whichever the users designate)

But any app could rearrange this and take or leave our indexer, run its own, aggregate indexes, or offer apps that interact differently with the indexer or homeserver data than our app does.

PKDNS basically commoditizes servers by giving users control.

The Nexus indexer creates a semantic social graph for matching keys and URLs.

Wanna try it? :)

Hmm, so the home servers are equivalent to personal nostr relays which just store users data. then for the social app you have a general purpose indexing server.

Would there be anything preventing someone building a desktop app that had the full indexing server running locally?

Id be interested in getting access, but I'm not really interested in the social app side. I'm more curious how the PKDNS and home servers work and how I could build my own. I've been thinking about building something similar for nostr + blossom and I'm interested in how you guys built yours

Yes, the homeservers are intentionally fairly "dumb" other than being normal web servers and having features to provide info to indexers,, and "speak" PKDNS. (Note they are definitely not relays and Pubky currently does not need such a relay network like nostr uses).

Yes, you could build a full desktop app for either mirroring our indexer, or indexing on your own, but note that making your own means your app need some way of collecting and learning about keys. Once you have a key list, then you can learn the data locations and retrieve everything (something nostr can't do, discover data with keys as authority.)

I do think you'll also be interested in the app, because it is wear we will end up expressing our semantic WoT features, and you will already see the potential with the tagging UX 😉

Exactly as I expected... AND MAKES TOTAL SENSE IF YOU HAVE ANY EXPERIENCE AT ALL W SERVERS *because* YOU UNDERSTAND THE UPFRONT COST of running them in their various forms.

FOSS community has *much* experience w this over the years. Some of the people on the "nothing can stop what is coming train" should look up the history of iMesh and what happened there from *2013 to 2016*...

nostr:nevent1qqsv9cjstp4wmayc96xkfzgat5h64j99tz6p34yemyjt4kgpnsvghagppemhxue69uh5qmn0wvhxcmmvqgsgeksa4tajm7x673gq2v7t56dkgkh6pjhhzdhrgxlpke4za8jmmkqrqsqqqqqpstyfh8