Anyone providing an HTTP tunnels for sats?

By the way, this gives me hope (+ nip26) that many Nostr developers would actually appreciate a more complex but efficient, offline first, durable and maybe even e2ee sovereign cloud.

nostr:note14z95vetnrgza0kevsnrdmjnzgynt0s03y5fl0jycfa7zwnkdtagq5xqv8a definitely the right direction and worth the complexity

Plebstr, also tried Nostr.band and Snort

From client point of view it will either send a UDP message to the DHT and get a response, or send an HTTP request to a proxy server and get a response.

You will only make these requests as frequently as you make requests to DNS servers (infrequently), it doesn't do what IPFS do at all, just a censorship resistant distributed dns server.

My issue with foo.i2p is that unique readable names is untainable, people will squat and buy and sell and it is very hard to keep that decentralized.

Using ed25519 keys, makes it so the key itself is the TLD, you don't need http://.tld ... instead you can just do http://

Phone numbers are not human friendly but we already know how to do good contacts UX over that.

It is not enough to just make up a TLD, who is going to run that TLD? What happens when they censor you just like existing DNS can? How to stop spam and sybil?

All these questions are exactly what pkarr.nuh.dev was made to answer.

1. Bittorrent DHT is how you maintain ultimate censorship resistance

2. If you don't keep republishing your DNS-like record it gets dropped by the nature of the DHT, so that solves spam and Sybil

3. Your relay/hosting provider(s) who you already pay for keeping your data, periodically refresh your records on the DHT

Most importantly I tested all of that and showed that a small server can keep up to 100k users records alive on the DHT with >95% availability

Once you add aggressive caching, it is a solved problem.

But it will demand switching to ed25519 as the root identity

Today I saw a reply from nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 and I couldn't see the note he is replying to, until I manually took the event key and relay mentioned in the reply tags and queried that relay myself.

If the original poster migrated relays since (think forum comments from a year back) then there would be no way to find that note again.

Even worse nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj himself can't actually migrate while ensuring all his notes moved, because Nostr events aren't In an authenticated data structure, full sync is impossible to verify.

While this works fine for what Nostr was invented for, to replace the general usecase of the Web, we need to a proper sovereign DNS equivalent like #pkarr, and we need user's data to be durable, not just host agnostic.

And yes ed25519 + key delegation is a must, and they will absolutely pay for their complexity by providing long lasting identity, and anyone who says this is not practical is bearish Bitcoin because Bitcoin doesn't mean shit for anyone who can't keep a key cold.

I really hope this gets implemented and tested soon because it is the hardest part about personal data stores in general.

You can't decentralize Twitter, and we said this 100 times, the only thing you can decentralize is storage and identity and maybe small worlds like chat rooms or social games and wiki.

The big open forums are bound to be centralized by the most successful clients with big fat aggregating backends, and then they will close their API, unless the data was already stored on sovereign personal data stores.

This can't be solved in a decentralized way, thanks for coming to my Ted talk.

Seriously, it can't be done, search is a big data business and that can't be done cheaply, even worse it is a natural monopoly, whatever search engine has the most compute will get the most users and if they advertise they get the most money to get more compute.

Nostr users who can't make peace with this will just leave, there is no such thing as decentralized search.

nostr:note1pchvc4ca0vucq3w8nv2fsvery76g08aaeqfsjp93x2spfjevsvqqxrwege

Use the mainline DHT, it is working and I verified it scales to 100 of thousands of users per relay and I had a cheap vps.

You can try it yourself.

```

npm i -g pkarr

pkarr resolve o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy

```

github.com/nuhvi/pkarr

Or try the proxied web demo pkarr.nuh.dev

Please use range-based set reconciliation

nostr:note15xf2lzp49q35l4pmvkjs05ql9m5dfxr6vm6sf936j2qzk7ejkpwsgk8scu

Waiting to see your code

Beautiful, than you very much.

No it won't, because that niche is solved by bittorrent and you can't do better. Nostr devs are notorious for brushing away "complex" optimizations, so they won't even try to copy bittorrent's efficiency. But even if they do, it is merely reinventing an already very well oiled wheel.

Is there something like TMDB api but for music? From Tidal maybe?

It is an expensive business but crawling the entire web is how search engines work, a global view !== consistent global view.. theoretically it is what you can do client side, but practically cost prohibitive so you would rather get it precompiled for a fee or ads

Excited about all paid storage solutions because that UX is the absolute hardest part of personal data store and I want to see all the experiments I can.

nostr:note1da788kjtmq0sk6qgemv93f7qxkjgtyqzf7h4q92qn96k20qsjl5qxwfxhy

Feeds are awful, folders are still the undefeated interface https://chiptune.app/browse

Remember, Pkarr already can abstract over Nostr keys, and if you go to my Twitter bio you will see that I have an nprofile there.

Building a stable storage with e2ee and replicaton efficiency, is what I care about, it can't be cleanly done over Nostr and Nostr doesn't want to support that anyways.

So why not, especially when stable storage -in my mind- is the only way to deal with key management, so that your identity is not a single private key you paste everywhere or held by a server, so basically npub doesn't even offer me stable identities either, especially not one I can use with Bittorrent/Pkarr.

I feel like you are over estimating the network effect and interop utility here.