Bring back Nostr “Testing” Events
This is the way 🦀
Make me think of: “The Count of Monte Cristo was originally published in the Journal des Débats in eighteen parts.”
https://en.wikipedia.org/wiki/The_Count_of_Monte_Cristo#Publication
Top left. Settings. Blocked. Then find their identity and unblock. Should work.
You can self-host Tailscale. https://github.com/juanfont/headscale
I don’t know any dev yet who’s cashflow positive or break even yet. That’s not considering their time.
Certainly possible to be zap positive tho.
Yep. I think statistical filters will be important to ease per-client effort. However it means you’ll need to double check for positive results.
Event clients sharing a filter for what events they already have and a relay filtering them out or similar.
I wonder if a compound filters have event been used, where it’s still never 100%, but you have two offset filters and it would need to be true in both.
Zaps can be faked and entirely vanity too. Its not quite that simple. Pretend I just zapped you 100,000 sats for your post. Then you zap this post 100,000 sats. It looks amazing.. but we’re just throwing the same sats around.
Client side zap validation is expensive and time consuming as currently implemented. Verifying on mobiles isn’t ideal today. Hopefully this can be improved.
I’m supportive of the motivation.. just cautious about excitement driven development rushing what’s already moving fast.
Streaming a Million Likes/Second: Real-Time Interactions on Live Video (InfoQ 2020 - LinkedIn)
They have around 100,000 devices connects per front end server. The FE servers are less computational however, and rely on dispatchers to forward them client events/data. Netflix was around 80K (few years old video).
I don’t think our wallet integrations are where they need to be yet. Both browser and native apps are prototyping wallet interop and integrations at present.
A zap isn’t the same as a reaction. A reaction could be any content, not just a relative of an upvote.
I’d also be concerned about forcing engagement to require Bitcoin usage. I’m fully supportive, however there should be a choice. Bitcoin adoption is a different journey for everyone.
I’d like to see some performance testing in clients for time-to-load images as examples. A direct host/source is going to be faster I imagine.
I suspect torrents may be too slow for normal use and may need to be the fallback - and clients are incentivised to make it fast for best UX. Unsure how this impacts the economics of it.
A benefit from torrents however is when something is older or less cached/recent, you have a common addressable was to query across a peer network for who has this. That’s where I think it adds the most value.
We can make paid seeders with Lightning as a BitTorrent extension, but would anyone really use that?
It’s possible paid relays may offer seeding and hosting media content for their users. I see it as a value add service.
Mobiles can’t really seed, so torrents will need to defer to a server somehow.
Added a PR for this repo to include client app Relay Auth tracking (NIP-42).
CC: #[0] I only know of Coracle
https://github.com/vishalxl/Nostr-Clients-Features-List/pull/12/files
GM. PV those new to Nostr!
