Btw, no bullshit licenses. Absolutely every is MIT.
Yeah, it's WIP, but could still be FOSS. We debated about it, it doesn't matter much until it actually works.
It's a bit discouraging to try to be helpful, then turn around to find someone use your words against you. I guess I am not use to social media and hate battles like this. I had left you a follow up reply with my view on why your concerns are overstated.
Anyway, I'm happy to hear, help, exchange ideas or re-draft as needed if there are no negative attitudes.
No te conozco, pero siento que estás siendo más destructivo/negativo de lo necesario. Dicho eso, tampoco sé cual es tu pasado con John, asà que puede que la negatividad sea totalmente merecida 😂
Igualmente, yo apreciarÃa si en lugar de ser critica destructiva pura hubiese algo que agarrar para ir mejorando. A mi personalmente me encantarÃa montar un directorio `/pub/nostr` en los homeservers y forkear un cliente Nostr para demostrar como de potente serÃa si además de lanzar las notas a los relays, las pones en una URI `pubky://`. Tengo el tiempo limitadÃsimo y quizá no pueda ponerme con esto en varios meses.
I'm happy to help rebuild if anyone wants to.
It's kindda unfair, because I helped build it once already, so of course the whole protocol already exists in my head. In retrospect, there is 2 implementations of it already, one pure JS and another rust/wasm.
Anyway, I think it's easy enough I could rebuild it without looking into any docs. Prob I could have an MVP of the stack, from Pkarr to a CLI social media client written in python in ~2 or less weeks. Just a guess, of course.
Interesting. This works for me. Can you verify you are not also subsetting with other filters (left top button)? 
@btcprague nostr:npub15xd2mmjnh3caykh77djsv73e0zkrp42jp5mwerx8f4m6su40wdvss7t3l3
IMO you had the best idea and it's still impractical due to obvious computation constrains. So yeah, everything else is a scam.
Both. There is full content indexers and light-weight. But currently on beta what you see is full content: it serves content to you directly and then the client can verify with homeserver. On currently release beta prototype the client does not perform the verification with the homeserver, but this is comming (it's a must, obviously).
It doesn't really "use 12 words", but it's an available recovery method. I think backup file + password is the way to go and also the best way to load up and restore your key on Pubky Ring signer.
Messages could be signed, but then you would be posting from Pubky Ring, this will be eventually implemented. There are many use cases for signing individual items, but the protocol does not enfoce signing because homeservers are the authority for your data, so it really doesn't need to be signed: you will only be protecting from a malicious homeserver provider and there are other better ways to protect from that.
I think it is probably very easy to build a service that send to your homeserver all of your notes (for permanent storage and discoverability). It will also be pretty easy to send as notes events from a homeserver. Difficulty will vary for each app.
Given that both protocols are open and neither has internal walled gardens, I'd be surprise if these "conversion" tools don't exist by mid next year.
I haven't looked too deeply into it yet, so I may be talking complete bullshit here, but so far my impression is that Pubky is 3 things:
1. signed entries published on a DHT that associate a pubkey with an HTTP server
2. HTTP servers that can host any file
3. a superstructure for reading content from these HTTP servers and turning them into a global social network
It's a very elegant structure that sound very compelling to me, but ultimately I don't see how it improves much upon anything Nostr has, and it has significant downsides and unsolved (hidden) problems that Nostr either solves or is trying to solve right now.
2 is cool, but not a very hard problem to solve once you have a way to find these user servers (and, also importantly, someone to host these servers mostly for free). Blossom is doing a similar job with files as first-class citizens.
2 is also not very useful by itself. To make a social network you need a way to efficiently pull content from user servers and display them to users. There is where they came up with 3, which sounds very similar to Bluesky's central big server which they call "Relay". It's a centralized system that cannot possibly become decentralized. It looks like Pubky has accepted that as the only way to do things, and they seem to be planning on hosting one such big server.
1 is trying to be the most decentralized, censorship-resistant system ever for putting out information about public keys -- and we may discuss if it achieves that or not (I am personally very skeptical that DHTs can scale, even though nostr:npub1jvxvaufrwtwj79s90n79fuxmm9pntk94rd8zwderdvqv4dcclnvs9s7yqzis going to boldly claim that this is not a topic worth discussing because "Mainline has already proven itself with its bazillion nodes and centuries of existence" truth remains that Torrents do not work without trackers, and no one knows what will happen with the DHT if it has to store billions of records from people all over the world -- https://newsletter.squishy.computer/p/natures-many-attempts-to-evolve-a is one scenario), but all of this mega-decentralization is completely useless if you don't have a decentralized way to load content from people you follow and have to rely on a giant central server hosted by one big corporation.
Pubky's idea seems to be that centralization on content distribution is unavoidable, so they aren't even trying. The idea of Nostr is that such thing isn't unavoidable, so we are trying.
> Pubky's idea seems to be that centralization content distribution is unavoidable, so they aren't even trying. The idea of Nostr is that such thing isn't unavoidable, so we are trying.
This is a fair assessment, though some nuances are worth highlighting.
Firstly, indexer centralization primarily becomes necessary in Pubky if your application requires a comprehensive, network-wide view of all homeservers—this is in fact something essential for pubky.app’s social functionalities. Features like search, semantic social graph inferences, and others inherently demand centralization due to the resource intensity of crawling the entire Pubky ecosystem, much like Google indexing the internet. I'm not uptodate on Nostr developments, but I believe it might face similar challenges in this regard, although I may stand corrected.
Importantly, an indexer in Pubky doesn’t necessarily need to handle content distribution; it only needs to guide users to content locations. The verification of content provenance still happens at the homeserver level. Indexers cloning data and serving directly, however, can enhance user experience by improving responsiveness, and I anticipate the emergence of both lightweight and full-content indexers. We are building Pubky Nexus, a full-content indexer, but it can be strip down to become lightweight as well.
We envision multiple competing indexers evolving, akin to the variety seen in web search engines today, despite Google’s dominance. While fully decentralized content distribution may have limitations, I envision (and want to dedicate effort to it) niche users with sufficient resources and interests could potentially run their own indexers, though they naturally only index a partial view of the network. For what is worth, I would like to run one at home.