How do #linux people get their apps today? What is good or painful about this approach? What is a missed opportunity for app distribution on linux? cc @Laser @jb55 @franzap @KernelKind

😂 View quoted note →

Google, meta, instagram, sloptok, amazon have spent billions of US war shekels and millions of engineering man hours on reducing load time, so that their ADD riddled consumers dont lose patience before the page loads. Ser @sandwich gifted nostr with a spec that helps nostr devs (e.g. implementing outbox) in nip-66 that is benchmarked to reduce load times by about 40%. Adding nip-66 is tens of lines of code. If you dont trust third party nip-66 providers, you can roll your own. By checking which relays are alive/offline/dead before checking relays you dont add complexity - you reduce and manage complexity in your app, as you make app behavior more certain (order of magnitude 1/2 connections to outbox are wasted without nip-66). Performance matters. Accept this, and improve the experience for your customers. View quoted note →

Barely any app devs as far as I’m aware implement nip-66 relay liveness checks e.g. for outbox. Nip-66 reduces feed loading time by ~~40%. https://github.com/nostrability/outbox View quoted note →

More outbox lessons learned for me, maybe useful for #devstr As far as I know 1. Learned that no nostr app uses nip-66 to check if a relay is alive before firing off requests 2. According to my benchmarks, by implementing nip-66, the relay success rate increases from 30% -> ~~75-85%, meaning fewer connections are wasted on dead relays. 3. Nip-66 is therefore an efficiency improvement, and is not necessarily a coverage guarantee 4. I have not measured time to outbox results yet. 5. No nostr app spot checks what outbox relays return against an independent relay to detect gaps. Nip-66 liveness checks return relay health, but do not verify per-author delivery. 6. Deterministic algos like greedy set coverage cannot be set up with a learning mechanism 7. Stochastic algos like coracle’s are able to implement learning, and benefit significantly - coverage improves the more the app looks up a specific profile 8. The theoretical CS algo I mentioned before (MAB-UCB) algo is not practical 9. 20-44% of follows dont have a kind-10002, which hampers outbox. From what I’ve seen so far the best starting point is coracle’s stochastic algo, with nip-66, and delivery scoring. https://github.com/nostrability/outbox cc @sandwich @hodlbod @fiatjaf @utxo the webmaster 🧑‍💻 @Mike Dilger ☑️ @hzrd149 @KernelKind @Daniel D’Aquino View quoted note →

The US and Eu are operating under the green new scam until coal plants are restored, built, and not strangled by bureaucrat edict View quoted note →

👀 View quoted note →

Gulag tech breakdown

vmfunc.re

the watchers: how openai, the US government, and persona built an identity surveillance machine that files reports on you to the feds

53MB of source code leaked from a government endpoint. 269 verification checks. biometric face databases. SAR filings to FinCEN. and the same compa...

Vibe check

A few years ago I asked the devs to run the benchmark on how much better (if at all) outbox is over using large relays. No one took up this question, so I started running benchmarks. A few learnings for me: 1. Outbox is proven better than using large relays 2. Three relays is the optimum for each npub 3. Three year old notes have an incredibly low survival rate, and are barely findable by the best outbox implementations (~~20%) 4. There are half a dozen algos not yet implemented by any nostr app to my knowledge that are superior to current algos for finding year old notes 5. No nostr app has implemented nip-66 relay liveness checks in outbox implementations to my knowledge 6. It could be measurement or methodology error - the relay/note indexer performs worse than outbox and large relays 7. There are poor performing outbox implementations Cc @balas @KernelKind @fiatjaf

View quoted note →

Don’t trust. Mine your own silicon.