Nuh

Working on https://mlkut.org, designer and maintener of https://pkarr.org.

https://nuh.dev

Public Key

npub1jvxvaufrwtwj79s90n79fuxmm9pntk94rd8zwderdvqv4dcclnvs9s7yqz

Profile Code

nprofile1qqsfxrxw7y3h9hf0zczhelz57rdajse4mz63kn38xu3kkqx2kuv0ekgpzemhxw309ucnjv3wxymrst338qhrww3hxumnwqgdwaehxw309ahx7uewd3hkc60w25k

Publishing to

192.168.18.7:7777

nos.lol

Author Public Key

npub1jvxvaufrwtwj79s90n79fuxmm9pntk94rd8zwderdvqv4dcclnvs9s7yqz

Show more details

Last Notes

2025-07-13 09:49:29 GMT

Substack is becoming the new website 2.0 champion after Reddit and Twitter went to shit. I am happy for the existence of such space, but I am sad that it doesn't fallback to open protocols for when the inevitable censorship and deplatforming kick in.
The most disruptive challenge to social media and the biggest revival of blogging, and we blundered it again.

2025-07-12 21:54:21 GMT

- reply

Same dynamic exists in Pkarr because relays. The difference is that Pkarr queries the DHT and relays in parallel by default and will always do so, because why not. So a relay used by everyone is very unlikely to be a single point of failure... because the parallel query to the DHT is not expensive.
Even if you are in browser, if only one of the relays you are using in parallel is honest and publishes to and read from the DHT, then no matter how small and obscure it is, it is still bypassing the malicious relays.
It is just too hard to censor.

2025-07-12 21:36:00 GMT

- reply

Good to hear, but this sounds like an adhoc gossip network. We don't need to reinvent overlay networks, we know that DHTs scale, gossip doesn't. Gossip only work when you are already cursed with the need to replicate a dataset in full.. for everything else, sharding aka DHTs are the optimal solution.
The 200 relays you reach, are not likely to be the ones I read from, and if it is likely, then it means these relays are under too much stress and they will churn or drop your data soon.
Nostr is good enough for sure, but physics is physics, and the Web needs a DHT or ICANN... these are the choices.

2025-07-12 21:15:39 GMT

- reply

If I run my own Outbox, how can I tell the whole world about it if they 10 relays every one reads from censor me by decree from USG under the threat of unpersoning the relays owners aka sanctions?

2025-07-12 21:13:22 GMT

- reply

I am arguing for the decoupling, but not as a novelty, we have a history of Internet and web architecture to support this decoupling as an important principle. Nostr ignored that because it was designed to serve one purpose (social media) where highly contextualised posts are the norm.
Of course now the revision of "nostr is for the other stuff and fix the web" is here because the social media usecase stalled, but here is where i come to be annoying and say no stop, the mess that was made while assuming social media, doesn't fit when you are trying to fix the web.
If you want to fix the web, you should fix DNS, because that is the only minimal layer that actually can be decentralised at scale, and is sufficient for all small world applications.
Anyways I don't think we have disagreements. I just wanted to defend DHTs honor from even more misunderstandings, not by you, but by people who would have read your posts and took them at face value.

2025-07-12 21:02:31 GMT

- reply

Even if you don't know anyone, you can run a local network in your town, and it only takes one node to find a node from the mainline big network, for everyone to be entangled in one big network... tell me this is not different from how nostr clients discover relays :)
Come on man, yes Nostr can become a DHT, a small one, but it isn't, not even close, it is not behaving that way and paid relays (the only sustainable ones) have no (almost negative) incentive in losing their advantage as the scarce common well known relays

2025-07-12 20:56:34 GMT

- reply

You think data submitted to the DHT is not signed and can be shared by sms too? Why are you still trying to push this false dichotomy?

2025-07-12 20:48:14 GMT

- reply

Not only is Nostr relays are orders of magnitudes fewer, and less time tested. and dns dependent. They are also not cheap to run AND have a conflict of interest since they double as service providers
This is the Mastodon and even Email fault, where the service providers can boycott and censor other providers.
But Mainline is cheap, extremely redundant and have no interest whatsoever in what is published on it. They don't compete with the services that are published on it.
This is significant in my opinion, you can't dismiss all of this merely as difference of degree... at some point it becomes difference in kind.

2025-07-12 20:38:09 GMT

- reply

Yes everything can be anything if you try hard enough. You can even search Google to find the newest incarnation of your favorite pirating index after the previous one gets taken down. Hell you can download HOST.txt from your friends by sms.
But at some level of generosity technical discussions become too unserious

2025-07-12 20:26:14 GMT

- reply

I know exactly what you are saying. But I don't care about Mainline vs Nostr. I only care about the technical details of Mainline because DHTs have too much bad reputation and I guess I am a bit autistic about it. You said that a certain 3 nodes are necessary, they are NOT, and there aren't any specific ones that are necessary.
This is strictly better and different in kind from mere redundancy of servers. It is a self healing mesh. That is not special though, Bitcoin p2p gossip and every overlay network is this way.

2025-07-12 20:21:35 GMT

- reply

Is this Chatgpt? Please stop.

2025-07-12 20:19:02 GMT

- reply

If these were necessary, why aren't they mentioned in BEP0005 or hardcoded in Libtorrent?
Also, take mainline crate, and replace the routing table with this node; relay.pkarr.org:6981 see what happens.
Also, once you bootstrap, call to_bootstrap() to cash your table to disk for next sessions, and use that for bootstraping and see what happens.
Come on now.

2025-07-12 20:12:38 GMT

- reply

This is false, regardless of Nostr or Pubky or whatever low stakes feud bitcoiners engage in instead of trying to fix scaling issues.

2025-07-11 07:57:42 GMT

Still killing zionists somehow after the most brutal carpet bombing and starvation campaign for two years.
https://blossom.primal.net/dce4350d4216a5967d5fa2cc6f8437257ff1b282c3baa85825bad778546a5c97.jpg

2025-07-11 05:59:48 GMT

#peergos is insanely cheap compared to any alternative, and there are no comparable alternatives that are open and solf hostable.
https://blossom.primal.net/eb213992f34faac15929dee1d4f13ad3ad8bb60750520142a7d77c351de4a60b.jpg

2025-07-10 19:43:21 GMT

The fact that Palestinians in Gaza are still capable of killing zionists soldiers to this day, is nothing short of a miracle. They are fighting to save us all from the most unhinged genocidal supremacist scum that ever had that much power and impunity.

2025-07-06 15:21:01 GMT

All bitcoin scalability solution fo and will require reliable cloud hosting that doesn't rug pull you, because in order for digital money to scale, seed wallets will have to be understood as a privilege for the very rich, for everyone else, money will be an encrypted file, and data integrity is going to be non negotiable.

2025-07-06 07:00:53 GMT

If you are interested in Mainline DHT, you can now simulate much larger local networks for whatever reason... this is a part of series of PRs and changes I am planning for, to allow developers to extend Mainline with arbitrary API, and have a better chance at bootstraping that API without getting Sybilled to oblivion.
https://github.com/Nuhvi/mainline/pull/5

2025-06-25 11:23:34 GMT

- reply

Man I wish I had enough money and pay you to work on Peergos, they really need some design work 😅

2025-06-23 16:42:59 GMT

zionists succeeded, from now on Americans are going to fight and they will continue to kill Gazans in peace and watch the USA fighting their war for them with popcorn in hand

2025-06-20 06:37:47 GMT

Any software that is only distributed as a daemon or a server with rpc should be avoided at all cost.
I am so sick of dealing with distributed systems in fuckin local integration tests, just because someone can't write a library.

2025-06-19 15:11:36 GMT

- reply

Remember this when you use a software where the developer rejects any responsibility or accountability for quality or security by calling his work "vibe code".
#nevent1q…35ft

2025-06-19 07:37:18 GMT

I think I found a promising post quantum alternative to Ed25519, not yet accepted by NIST, but even if I Yolo it and use it to create a post quantum version of #pkarr I will have to convince people to bootstrap a DHT or convince Mainline users to support that BEP. Not easy.
Still, I think we should start working on this soon.

2025-06-16 16:46:44 GMT

- reply

One of the reason I like Peergos, they went to an extreme length to sandbox all their apps. Not practical for all apps, but for things that only need to read and write from and to your data store, it works, and it protects your data from all forms of "phone home".
#nevent1q…w2r6

2025-05-30 14:06:03 GMT

Very good fake account for @nprofile…u0w6 ; https://primal.net/p/nprofile1qqsfjp55tqw9syjy38gtpr06f5482ga8zwck4q56p0qkrtvzhl7uj9gqcu5jn

2025-05-21 14:18:43 GMT

- reply

You can remove IPFS from Peergos and no one will notice anything, Peergos only uses IPFS to enable users to swarm chunks of the filesystem among themselves without permission from any server... of course no one does that shit... so IPFS is irrelevant to this conversation, but it is always a distraction

2025-05-21 13:38:20 GMT

- reply

I don't know how to argue with "no one asked for it on Nostr yet" when I am asking for them, and literally millions of people are spending arguably too much money for Proton Drive to have exactly what I am asking for but without the open API.
But again, if you don't care, you don't care, ain't no arguing with that.

2025-05-21 13:20:29 GMT

- reply

I am not aware of people self hosting.. but it should be doable it is open source and it should work just fine.
The main downside of peergos is a centralised PKI, but we know how to fix that. And Peergos developers will add something similar to Pkarr eventually.

2025-05-21 12:24:45 GMT

- reply

You are wrong, but hey, try it and see if you can build an encrypted filesystem on Blossom without changing Blossom and without asking clients to do prohibitively complex work on their side, and while reclaiming storage from previous overwritten state.
Sure your needs might be limited that you can come up with ad hoc ways to satisfy them with Blossom only and few extra tricks on top, but you can't solve for the general problem without servers helping.
I can write about all the challenges involved in a more coherent manner, but honestly I am not sure anyone cares. So it is one of these things where I have to just build what I want and if people think it is valuable they can help themselves to it.
That being said, even without encryption I think I did a very good job while working on Pubky combining WebDav with cryptographic identity and authentication, and people can use that or learn from it if they want. Or not.

2025-05-21 12:09:13 GMT

- reply

@nprofile…aswu of course, there are apps that cant be built even with a Proton Drive like API. Most notably apps like Twitter or any app that needs aggregation of data authored by multiple people and custom API endpoints that are tailored to the UI needs (backend for frontends) ... but I always argued that these are lost cause.
I just want to see something like Proton Drive but open for all quiet apps to flourish there... I dont want the next Obsidian to be closed source, nor its cloud sync to be centralised.

2025-05-21 12:05:43 GMT

- reply

Good for you, but that is not what I am talking about, encrypting blobs is easy even on client side and a dumb server, but that is too far from an e2e encrypted filesystem where key management, access control and granting and revoking access is neatly packaged in an SDK.
That is what I am talking about and it is the necessary (and sufficient) feature to build any cloud application where the user come with their own storage... I know that because every Google/Proton Drive provider immediately starts offering stuff like Docs and Sheets etc. Because they can.
Now you can use blobs on Blossom to make up a Cryptree like Peergos, but Blossom is not smart enough to help you with access control (beyond encryption, which is imprtant), and not smart enough to handle the difficult key sharing story, and most importantly it is not smart enough to know what nodes in that tree needs to be deleted to reclaim storage.
If you don't feel the need for an e2e2 key value store or filesystem... then you are not building the apps that do, my point was if we are going to build an open storage protocol, might as well build what is necessary and sufficient for any app that is analogous to native apps but with cloud storage instead of local storage, instead of building Blossom then realising it is not good enough later.
As usual, I invite you and others to look at Peergos or just imagine what you would build if every user had a sovereign version of Proton Drive with open API.

2025-05-21 10:02:38 GMT

- reply

Yeah they are alright for public immutable files .. that's what they were designed for and they do well.
But the exact same feature could be achieved with WebDav... so I am not really sure what does Blossom offer more than the ancient and equally simple WebDav... even if you wanted to use nostr keys instead of web fingers or usernames, you could fork a webdav server to support that in a weekend, and you get all the webdav features while at it.

2025-05-21 09:27:35 GMT

- reply

You are under selling the need for ordered key value store or a filesystem interface.
Without this consistency of an ordered yet e2e encrypted lists, plenty of apps are simply impossible, unless you fake it using a mutable file and embed an sqlite file in there, however this will suck ass to maintain AND Blossom doesnt have mutable files at all.
Think; how do you build every app in Google suite or Proton Drive apps without this ability?
Or think instead; why do we have filesystems and BtreeMaps if we can build apps with random immutable files?
Finally; you can't slap privacy on top ... it is the HARDEST part, someone has to build this once for everyone and servers have to be involved.. think of all the access control and key management and defense in depth where servers don't give encrypted files to random people even if they can't decrypt it, because eventually they might be able to... etc.
My point is, Blossom won't cut it. If you insist on using it because the availability bias... fine, but maybe check Peergos to get an idea on what can be done.

2025-05-21 08:43:38 GMT

- reply

I think that is fine. I however don't like the idea of many servers... users (including me) won't enjoy managing all these relationships.
I am not talking about the multiple providers here, for this people can run a mirror on their own device or use a friend as a backup.
I am talking about Blossom being insufficient alternative to Proton Drive or even WebDav... so now if you need end to end encryption and sorted key value store or filesystem semantic... you have to either build that on Blossom only to realise it is a bad design since the server is not doing its part of enforcing access control OR you have to build entirely new kind of servers.
My point is, everything Blossom (or any content addressable chunks server) can do, Proton Drive servers can do, but not the other way around.
So why bother with Blossom at all? Yes they are simpler, but they are not complete and the need for the complete solution doesn't magically disappear just because you wish you didn't need them.
So you tell me, if there was an open alternative to Protons Drive, wouldn't keychat apps benefit from that in ways Blossom can't help with?

2025-05-21 04:41:29 GMT

The idea that all you need to pass bitcoins to your future self or children is a seed phrase will hurt people. Eventually most nodes will be pruned and you will have to provide the block headers and merkle proofs of your utxos to spend them.
Even if this never happens, you shouldn't depend on strangers for data availability necessary to secure your wealth.
Moreover, most users will never have a utxo at all, so they need to backup their vtxos or other forms of client side validated transaction data to own anything.
Open, secure, durable, and reliable cloud storage protocols and infrastructure are necessary for all kind of applications, but they are necessary for property rights on the Internet too

2025-05-19 14:35:47 GMT

Unit bias is a real problem, but it doesn't matter until we find a better alternative to Lightning to actually give people few bitcoins without asking them to "open inbound liquidity" and expect them to not laugh at us.

2025-05-14 08:00:34 GMT

- reply

My baseline is Phoenix LN wallet where presumably the worst that could happen is they close the channel and I pay high fees, or they try to steal and a non custodial watchtower can bail me out.
If Ark is a step forward (no need for opening channels) I hope there are no steps backwards on the other end.

2025-05-14 07:57:45 GMT

- reply

Ok it is nuanced I will grant you that, but I think our goal is that users can receive bitcoins without any more of a ceremony than having an address, and that money remains passively safe somehow, even if by employing a watchtower, as long as this watchtower can't steal (only fail).
This is the least people expect from payment systems.
However, operational/maintenance fees are acceptable, but losing all the funds wholesale on a such short timeout is just not going to fly.

2025-05-14 02:07:14 GMT

- reply

If by "technically" you mean according to consensus rules, I hope you realise not a soul cares about that, not users and not regulators.
Just because people send sats to custodial LN providers addresses, doesn't make that a donation.
You designed this contract (I presume because that is the best you can do with Bitcoin smart contract), but you didn't design it to enable time bomb donations to operators... that is bug not a feature.
Unless of course you do advertise Ark as a time bomb donation to operators, then good luck with adoption and actually good luck with regulators still.

2025-05-13 13:19:26 GMT

- reply

Yes I mean this requirement to deal with expiration of vtxos.
I have a server, but I don't want to trust it, I want it to help me keep my vtxos safe if I didn't open my phone for long time (actually happens, I haven't opened Pheonix for ages and forgot battery mode on for weeks), but I don't want the server to be able to steal, or more importantly I don't want to run a server for others that is legally a custodian of money.

2025-05-13 08:23:22 GMT

- reply

Lazy question (promise to read more later); is there any way for a non custodial server to deal with the "remixing" of vtxos on my behalf?
Asking because if that is at all possible, I would like to add that as a native function or a plugin to the same Homeservers hosting users private data and republishing their Pkarr keys to the DHT.
Or in Nostr terms, user's paid relay.

2025-05-11 11:38:18 GMT

- reply

Perfect.

2025-05-11 10:28:25 GMT

- reply

I again disagree, but maybe because I am much more of a saver than spender.
But I really do think stable prices are not that hard nor do they need central authority, at the end of the day stability of Fiat is just a small part of businesses concerns, the rest is hedging against volatility of prices of inputs, which is not done by central planning, but through futures, and I see no reason why can't there be Bitcoin denominated futures for the inputs of the digital economies.
There is also over collatorization and somewhat trustless oracles like the UTXO analysis thing...
Anyway, I think it is doable, but I don't personally care about it that much, if you do, I hope you will work on it instead of thinking it is impossible to fix.

2025-05-11 09:37:46 GMT

- reply

As for the real physical economy.. that is a bit more tricky, but at least where I live, even businesses that pay taxes, would still prefer taking cash, so why can't Bitcoin win if it had as good UX and as good liquidity as cash?

2025-05-11 09:36:28 GMT

- reply

Not sure what you mean, but I don't personally prefer wishful thinking, on the other hand there can't be a "plan" in a distributed system. The best one can do is think about the problem, possible solutions then cooperate with others to build these solutions.
My current thinking is; maybe if Bitcoin can scale much better, it would be used more for internet commerce, at least as much as Tether is being used in developing economies, which makes KYC chokepoints less destructive.
If you think this is a red herring, and a scalable private Bitcoin won't make a dent, please explain what do you think the main problem is? And what do you think we should do instead.
I can make a counter argument to my own argument; people want fiat not Bitcoin because they have to pay taxes.
But honestly that doesn't make sense for Internet commerce, at the very least not for digital services where the entire market can be ungovernable because it is hard to observe and meter... stuff like VPSs and VPNs, SaaS and apps etc.

2025-05-11 09:12:09 GMT

Number go up, but the number should be the people making a living on the Internet without a kyc permission from the empirial center.

2025-05-04 10:10:07 GMT

I want to thank @nprofile…5cq2 for being my main outlet to have opinions on Bitcoin without being told to go back to the kitchen, despite usually being a valid response to my ignorance.

2025-05-04 10:01:12 GMT

- reply

I haven't tested this myself yet, but I encourage everyone to try it if they want to play with ICANN free secure connections without changing anything about their existing application.
If i remember correctly @nprofile…rzrk did this first with NWS, and this is the Pkarr equivilant, and I think it is one of the things you can use from the Pubky ecosystem without commitment to the rest.
Of course you can build your own version, but hey free open source, take advantage of it.
#nevent1q…nd4s

2025-05-04 09:57:51 GMT

- reply

While I can't speak on behalf of Pubky, I actually noticed they did some work to make it easier to run a proxy infront of arbitrary http servers and allow it to being accessed with a Pkarr key, including TLS.
That is good work and I hope people from outside the team notice it and leverage it, I wanted to build that myself and I am happy they did.
https://github.com/pubky/pubky-tls-proxy

2025-05-04 09:53:07 GMT

- reply

1) I would obviously answer with yes to all these questions if I am building something that is more tolerant to small worlds and more similar to Matrix group chats, because obviously home servers work for that better, we saw it in SMTP and Mastodon and Matrix and almost all message passing architectures and they are plenty.
2) As you know I can't talk on behalf of Pubky anymore, but Pkarr definitely can allow servers to be accessed without ICANN DNS, that is one of the things Pkarr offer Pubky homeservers and possibly indexers.
But the other unasked question is are you actually better off with Nostr events over websocket queries at this point or are you better off with custom HTTP API?
If I had time (new job and quite busy) I would have worked on #mlkut more and offered everyone a complete solution for identity and key management, e2e encryption with minimal trust in servers, and an SDK to use that architecture to build whatever apps you want, it wouldnt give you a global feed and a fun playground of public data, but I established already that this is a non-goal.

2025-05-04 06:11:40 GMT

Whenever someone says Microblogging is not the main usecase for Nostr, I want to remind you that the entire architecture was based on the needs of low latency public threaded discussions and fresh feeds.
If you gave up on that, at least take a chance and rethink the choices that was made and their cost. Can you simplify? Can you increase reliability? Can you gain more consistency? If you no longer face the demands that the protocol was designed to meet?

2025-05-04 04:40:40 GMT

Yes, but you can't make it easy. There are no servers that don't need maintenance, at least for electricity and connectivity issues. But also bugs, security issues, etc.
The closest we came to this is VPSs on the cloud, and I support that a lot, but still, these friends need to know how to deal with emergencies.. just ask anyone who is running a mastodon instance.

2025-05-03 23:21:53 GMT

- reply

If you plan on building any p2p network, Iroh should be the first thing to try, and you most likely won't try anything else, because it just works.
Caveat is; make sure you actually need p2p, because Iroh can't magically solve all the other challenges inherit at leaderless distributed systems.
#nevent1q…janj

2025-05-03 07:20:08 GMT

- reply

No need for users to run servers for that, all of this can be done client side as long as you have mail system to share keys through.
Yes you can't immediately get a permission to read or write if none of the moderators are available, but the scarcity here can't be solved by an always on server, given the fact that you want humans to moderate spaces not robots.

2025-05-02 02:57:14 GMT

- reply

Remember... Nostr already doesnt have gossip and actually started as a critique of gossip (Secure scuttlebutt), and Negentropy was invented on top.
Yet somehow you make it sound like Nostr relays are inherently gossip friendly, well, extend the same grace to Pkarr relays.
You get exactly what you want, but also a DHT to fall back to when your system inevitably fails for the vast majority of web needs.

2025-05-02 02:54:16 GMT

- reply

Same way you plan to do it in your system, build a gossip network on top to share the scrapped data from the DHT or make a network of relays that forward things to the DHT but also gossip it with whoever wants to download it all ... or whatever.
There is nothing in using the DHT that makes using gossip in parallel impossible... the only thing makes gossip impractical is that it is inherently impractical.

2025-05-02 02:36:47 GMT

- reply

You are just mistaken. DHTs don't stop you from what you want to achieve as futile as I think it is, but the DHT doesn't make it any harder.
My relay has thousands of packets, nothing can stop me from gossiping with other relays, I just think it is a bad idea.

2025-05-02 02:17:00 GMT

- reply

Says who? Who is preventing you from scrapping the DHT and build a push system or share what you downloaded on a USB stick?
I did my best to explain why you can't have the features that a DHT offer any other way, I never said you shouldn't do more on top.
Also, privacy can be achieved in other ways.
It seems you weirdly want to download the entire web and read it locally because that is awesome and private, sure, do that.
My question remains; what about phones and people who don't have 500 GB of RAM or storage at all? How should they find the data they are looking for?

2025-05-02 02:01:01 GMT

- reply

Good for you, not sure how is that relevant for rest of us and our phones, should we all query your RAM? Or who should we query?

2025-05-02 01:42:38 GMT

- reply

This a misunderstanding about DHTs.
1. You don't need to run a node, you can ask for data in a client mode, just go to Pkarr repo and run the examples, start the process make the query close the process, in and out less than the time to open an average Web page.
2. No one said don't use relays to cache data from many people's queries, no one said don't gossip and cache long term on top... what we are saying is; we need a source of truth that scales and we can fallback to when data is not available in your private cache that you got from your friend on a USB stick.

2025-05-02 01:06:44 GMT

- reply

Lightning is literally a network of mutually trusting nodes, directly or indirectly through a payment channel.
It is not a gossip network trying to store and retrieve ever growing set of data reliably and performantly.
I want to remind you that I suggested RBSR paper to Hoytech and helped with Negentropy, but it doesn't work for what you want to use it for. It works for passively replicating data you are interested in, it doesn't magically make all the data available to everyone, and if the data is jot available to everyone, then you again have to deal with the question of ; how to find who has the subset i am looking for in less than 500ms
The answers we know of are;
1. A structured network (DNS/DHT)
2. Small set of servers (like ten popular relays)
If you are happy with (2), fine, but then you have to explain what incentives do they have to serve the entire web (costs a lot).
But what you can't do is claim that you can either have full replication of an ever growing data across thousands or millions of nodes, OR claim that you can have partial replication across 1000s of unstructured nodes and have fast queries.
At least not with extraordinary proof. So maybe start building and let's poke at it and see what happens. Or run a simulation or something.

2025-05-02 00:56:13 GMT

- reply

Bittorrent isn't at all what you are describing, when. Peers are gossiping they are not sharing an ever growing dataset, it is a static file, and if it was a changing data set they would necessarily be discarding portions of it because they don't have infinite storage. In fact most seeders Immediately delete the static data as soon as they are done with it.
You can try to slow down the data growth as much as you want, but the best you can do is make it as expensive as a bitcoin transaction and make it take half an hour to hashcash an update, but ignoring the awful UX of that, the data still grows, forever.
How many nodes do you expect dedicating 100 gigabytes for that? Definitely not millions or thousands... definitely not as many as bitcoin nodes since it is not as profitable or necessary to store the full ever growing set.
And then these few nodes have to serve the entire Internet, and they become easier to control or attack because they are few.
You will never be able to have the full dataset, you will have to discard data, and the moment you start doing that, you will realise that people trying to read need to find out who has the parts they need, and they can't because there is no structure. So they will have to ask everyone, and that is exactly what a DHT is meant to make scalable; how to ask log20(n) nodes instead of n nodes.
Anyways, just build it, and see if you can survive spam without degenerating into a handful of nodes like an abandoned Bittorrent infohash.

2025-05-02 00:39:58 GMT

- reply

Please tag me when you build the system that you think is simpler than a DHT, so i can poke at it. For now what I have is DHTs that work in theory and in practice. I claim that gossip persistent replication will always degenerate to centralisation, and have long list of historical case studies, and nothing would make more excited than trying to break another attempt, and failing.

2025-05-01 23:45:10 GMT

- reply

Bittorrent had 15 years to develop a system where the gossip part can't be spammed/bused and where sharing data is fair, and nothing came up better than good old trackers.
My point is, the only system we know of where gossip works at scale for persistent data is bitcoin, and that is because you have to pay fees to gatekeepers who themselves have to pay in a verifiable scarce resource.
And it seems you are reinventing that by thinking in the direction of hashcash, where a proof of work entitles you to store your data.
The problem is, hash cash was already invented to solve the centralisation of email by countering spam, and it failed miserably, and will fail again every time, I bet.

2025-05-01 22:36:47 GMT

- reply

Massive lists are cheap to store and cheap to search through. And the somehow is a question of ownership, we know how to make collaborative lists managed by owners/moderators.

2025-05-01 22:31:25 GMT

- reply

Got it, this is usual gossip vs DHT question.
I think you are underestimating how vulnerable to spam this gossip network will be, and how expensive it will be.
There is an inverse relationship between cost of nodes and their decentralisability, and I claim that in a system with no fees for creating new inputs, the only stable configuration is a consortium of small mutually trusting servers, basically like Email.
But of course if that is not convincing, we can always try things in practice.

2025-05-01 16:21:00 GMT

- reply

I agreed with most of this until the end, the question is how often are you going to make a query to something that you haven't cached before. I call this the cold lookup.
And the answer to that is the vast majority of the time for two reasons;
1. There are more URLs on the Web and more endpoints than you can cache, and if you want to replace ICANN DNS, and not just contact list in a social app, then you should expect that most URLs are seen for the first time or it was evicted from your limited cache.
2. You want to support stateless clients, so caching at relays is much more reliable than expecting every client to start with it's own equivalent of host.txt of the entire web
Again, we already know what works for the general purpose, and it is not local host.txt.
But I am not saying you shouldn't use local caches if you can, you should, and Pkarr encourages that, but it is just one layer of caching, and without the falling back to the DHT, the UX really doesn't work, you can't take a step backwards from the status quo, especially when you are already asking users to do the hard thing of managing their own keys, you can't add to that URLs that have a 10% chance of working and "depends".

2025-05-01 11:39:16 GMT

- reply

Is replacing DNS (structured network) with manual gossip a step forward or backward?
Mainline DHT has millions of nodes, so for any given moment in time there is a capacity for billions of small packets.
When you introduce a caching layer (relays) on top, you get the structured (yet flatter) hierarchy of DNS, where the DHT is the alternative to root servers.
You combine that with the natural semantics of DNS, especially TTL, and these relays now can know when to check the DHT again.
Then you only need the DHT to contain your data only often enough for relays to pick it up.
It is not about efficency or correctness, it is about the UX and DX and reliability of the system... remeber that DNS started with manual gossip of host.txt contents... this didn't scale, why try it again?

2025-04-30 08:55:23 GMT

- reply

Worst case scenario that just makes centralised mining pools even more profitable vs miners that are only getting transactions from the mempool.
Best case scenario, another gossip network emerges, with simple enough code base that miners don't mind running in parallel to Bitcoin Core to hear about non standard transactions. Even if they don't trust it they can firewall it one way or another.

2025-04-30 07:12:55 GMT

- reply

This won't stop Citrea but would motivate them to use the OP_RETURN since they have to contact miners directly anyways.
Not a bad outcome.

2025-04-29 06:12:23 GMT

Bluesky metrics are steadily declining, and that is the network that has the best chance of going mainstream.
It is time to stop caring about global feeds and just make our small-worlds web better and more sovereign and be happy with that.

2025-04-24 08:46:22 GMT

- reply

What are you working on/want to build?

2025-04-22 11:00:55 GMT

RSS readers are good in theory, but in practice, no one can trust that the feed aggregators since the original feeds are not signed.

2025-04-22 10:45:17 GMT

- reply

Interesting 3rd party indexing without signed data? Impossible.
#nevent1q…glch

2025-04-20 08:02:28 GMT

- reply

All blockchain scalability solutions do is to compress history to almost nothing, then post the state diff to the chain every now and then.
Well, that means the l2 state can only increase in size by how much state diff you can fit on the blocks of l1.
So you can't onboard a million user in a single state diff, nor can you update the accounts of millions of users in a single state diff.
The account model is absolutely impossible to scale. Unless you bait and switch, using the l1 chain for timestamping and then dump the actual state on another layer.
But now we are back to the Interplanetary filesystem bullshit.
In practice only you and few others are incentivezed to store your state... but now congratulations you just invented client side validation.

2025-04-20 07:53:58 GMT

The reason client side validation is perfect for scalability, is that we can compress history with zero knowledge proofs, but we can't compress stuff like utxos.
This also means we can infinitely scale digital cash, but the "world computer" (usually means rich public statefulness) can't scale.
Again, indexers (search engines, feed curators, matching engines, etc..) will never be decentralised and censorship resistant as Bitcoin... for the same reason; too much state.

2025-04-16 16:54:06 GMT

- reply

This can and will (if worth it at all) happen to any Pubky indexers or Nostr relays that capture majority of eye balls. And when they comply, because they must, it will be effectively the same as shadow banning.
Play search engine games, win censorship prize.
If you don't want to deal with censorship, don't get big, and don't work on problems that requires big servers to solve them, or build a blockchain and make each post cost $20.
There sincerely no third options.
#nevent1q…acpr

2025-04-04 07:23:15 GMT

- reply

That is a gamble with >90% chance of failiure, that you can only make after you have your finances in order, to some degree at least.

2025-04-03 08:39:59 GMT

- reply

I agree with this, but as a non-billionaire I would like to tell young folks; take care of your finances first.
#nevent1q…3f7p

2025-04-02 04:57:07 GMT

I think there should be an option to Mute someone on timeline but not on replies, and maybe an option for the opposite. People are not equally annoying in both realms.

2025-04-01 13:34:10 GMT

- reply

No it is not a hard problem, the key rotation problem is simply impossible to solve without reinventing Bitcoin, and the user on boarding problem is trivial solved by web fingers.
They just decided to pretend to be doing something they either knew impossible to do, or worse.
The user adoption wouldn't have been affected if they just gave users usernames ... unless you mean the smoke and mirror of decentralised identity helped adoption, but I suspect no body really gives a shot about that.
Which is why I don't fuckin understand why are they confusing everyone.

2025-04-01 13:17:40 GMT

- reply

You literally posted him lying by ommission, he is pretending that people Mirroring the centralised directory means anything different from just a TLD. That is a LIE. If you sit down and analyse it you should be able to see why this key rotation and DID is just a circus without a Blockchain like Bitcoin.
But the real issue here is, no matter what I say, it won't matter, because everyone decided to believe this bullshit no matter what and pretend that the nice people because they are nice achieved the impossible.
Ok fine.

2025-04-01 12:56:07 GMT

- reply

I didn't say they are not fine, but Farcaster is honest about what they are doing, Bluesky made something that is not different from a TLD and insists that it is, and confuses a lot of people.
I wouldn't have any problem with them if they just said this is a centralised PKI. But they keep saying that it is not. That is a lie, no need to worry about it beyond just knowing that this is a lie.

2025-04-01 12:44:04 GMT

- reply

Then why didn't Bluesky just register a TLD instead of pretending to have made a decentralised identity?

2025-04-01 12:09:22 GMT

- reply

We already have ICANN, did:plc offers nothing new only worse, but the intellectual dishonesty about this fact should tell you what you need to know about Bluesky dedication to digital sovereignty.

2025-04-01 07:59:41 GMT

I have to admit, every time I see a screenshot or link from Mastodon I get envious of the quality of people and conversations there.
This can very well be a selection bias, but I might cave in and create a Mastodon account.
I just wish Mastodon was using Pkarr, so I neither have to setup a server nor worry about who is the first server I sign up to.

2025-03-31 17:30:20 GMT

- reply

The reason to stick with Nostr is getting grants from Nostr enthusiasts... but if you need that more than flexibility to address your market, then you are doomed anyways in my opinion.

2025-03-31 16:54:24 GMT

- reply

Lol... i literally saw Bluesky making breaking changes to their API before... not sure what magic do you think Json schemas have to prevent breaking updates.
Man, people really buy these claims!

2025-03-31 16:52:29 GMT

- reply

I think you are thinking of the Matrix Protocol... which plenty of governments already using for what you are saying instead of relying on American companies like Slack.
If I were you I would start playing with Matrix sdk before reinventing this wheel.

2025-03-31 16:30:13 GMT

For anyone who cares, the reason I a argue for a sovereign e2ee filesystem, is because that is the only thing we can make interoperable between apps... just like POSIX and files in general are the only interoperability success story in history.
What I consider feasible is taking that and make it Web native without getting locked in platforms like Google Drive.
Once that is in place, let the best app developer win, and if one file format becomes very useful, we reverse engineer it like we always do, like interoperability always worked; forcefully.

2025-03-31 16:19:43 GMT

- reply

And of course, the moment Bluesky decides to change their API a little this integration will break.
So what was the point? If you are not going to have stuff as stable and stupidly hard to change as web api, then why pretend you have interop?

2025-03-31 16:13:52 GMT

- reply

No not via the lexicon, via actual literal code, someone had to write the code for this to work, the Lexicon, the absurd JSON schema offers absolutely nothing.

2025-03-31 16:12:44 GMT

- reply

Ok, I will bite, what does Nostr offer businesses? Because my basic bias is that it offers absolutely nothing, if anything the shitcoin Wallet Connect offers more because at least you know people who use that have money and likely to waste it on stupid stuff.
What does an npub and very unreliable relays and extremely small audience offer businesses?

2025-03-31 16:08:20 GMT

- reply

You will publish your specs mainly to say that they are open. But not a soul will bother implementing them, and for a good reason, you can break the spec at will, otherwise you are destroying your ability to iterate on your product, and suddenly the random zero users devs demand that you take their consent before you update your schemas.... Lol won't happen.

2025-03-31 16:05:42 GMT

- reply

Being able to embed stuff has nothing to do with interoperability or lexicons it just means open APIs for extensions/widgets.
Unix apps can be piped together with a common stdin/stdout interfaces... but they don't have to publish specs on how do they behave.

2025-03-31 15:41:10 GMT

- reply

Why would you do all this work when you can just ... not? What is in it for you as a man trying to feed his family?
You have every incentive to reverse engineer Damus and Amythest schemas to attract their clients... but why would you make a new feature and tell Damus and Amythest how to implement it so their users never have a reason to use your client instead?

2025-03-31 15:38:40 GMT

- reply

I actually adopted this for Pubky, but I still think it is useless... no one has any incentive in detailing their schemas just so their competitors can steal market share easier.
Interoperability will never work, because there is no incentive.

2025-03-31 15:35:38 GMT

- reply

You should focus on Twitter and Facebook then, same centralised identity and much bigger market.
If did:plc became like ICANN, they would have spent too much time spewing bullshit just to become what they should have started with; registering a TLD and give people domains on signup, instead of this DID garbage.
And the 12 weirdos are not businesses by the way, businesses don't give a fuck, hell even presidents their didn't care enough to point their domain to the did:plc.
If you are in it for the business opportunity, make sure to not get high on this supply, if you have to sell it to business good for you, I am rooting for you, just don't confuse yourself.
Most importantly; don't ignore all the signs that Bluesky users don't give a shit about any of this, so if you build a business assuming there is a market for digital sovereignty enthusiasts... you are going to lose your shirt.

2025-03-30 14:58:03 GMT

- reply

As I replied earlier, you can't sign everything that the indexer serves, so the only option here is that you go read the original post from the homeserver if you care.
Sure signatures might have made that slightly better, but again many or most of the data the indexer serves simply can't be signed by the author.
Anyways, if you showed the team that signatures can materially improve Pubky, nothing in the protocol will prevent them from adding signatures, but they may still choose to not bother because the juice is not worth the squeeze.
I am happy that i didn't force my personal opinions of signed merkle trees and end to end encryption from the get go, as that would have delayed the app at least a year.
Now the team can do whatever they want. But at least the app is already here and ready to prove its design thesis which is entirely orthogonal to this conversation.

2025-03-30 12:21:01 GMT

Now you can see what others are uploading to the most decentralised and persistent blockchain ever... this is going to be bigger than Bitcoin in no time. https://plc.surge.sh/gallery