https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extinguish
this was a real threat by big companies to the open web and now also is to nostr’s existence nostr:note1dlcjttukfe8actpy94qadep2uxme3zlqermkx5nyte58h02snnps0p2ee5
we are at the extend until no one catch up stage of this meme I made back when Primal first launched
advanced search, custom DVM specs, etc
then kill off the independent nostr clients and you have achieved an influencer controller and funded echo chamber 
Hi, All.
I recently developed a WebSocket server.
I plan to embed this WebSocket server into a future Nostr relay that I will develop, with enhanced documentation, comments, and testing.
https://github.com/Hakkadaikon/websocket/tree/main
By the way, there's something I've been thinking about lately.
Nostr runs on top of WebSockets, And WebSockets run on top of TCP/IP.
In the case of TCP/IP, data cannot be received in bulk using a system call, so we believe there is a problem in that it is difficult to improve performance beyond a certain level.
I believe that if Nostr were run over a UDP protocol such as WebTransport, RUDP, etc..., Nostr relay could operate even faster.
For a plain Nostr relay delivering text events, probably won't need to go this far.
However, I think this Nostr relay can be useful for delivering volatile, streaming, real-time data.
In the future, I plan to create a PoC that runs Nostr on the UDP protocol.
What do you think?
Comments, positive or negative, are welcome.
#nostr #grownostr
WebTransport would be the best, as there is browser support, and QUIC does most of the hard lifting
giving someone ecash is like giving someone a check
you don’t know if it’s real until you cash it in, which is not instant, and which costs the recipient fees
the mint could say 500 sats of your 1k sat payment went to fees
🐈🚀 nostr:note10jwmacqadnu8p3mhqhn63k57jd344tvmtan9lq5nle0cywqg20ks2rzm0z
Wil it have any “sponsorship” spots or any sort of prioritization
Notice: you must explicitly enable this
on Lightning, there is a unique ID attached to any payment
anyone on the path knows the amount of the payment and the payment ID, and which node it is going to and coming from
using certain heuristics, it is possible to identify recipients, and senders with high accuracy, by only controlling some of the nodes on the path, which can be achieved by well funded chain analysis entities nostr:note1k6zvw7rg3dv8mcmzgn9w0k90g95y8mw04tftm25ke2htfpkmutyqe0h3kr
MEV is already happening partially to some extent with any form of on chain contract
LN inherently introduces MEV in the case of force closes and denying penalty transactions, for example
someone I know has reported significantly more issues with LND instead of CLN and do not want to open more channels on their LND node
I moved from LND to CLN due to stability issues
multiple CLN/Eclair and even LND noderunners I know are experiencing FCs with LND nodes and only LND nodes
I reindexed my CLN node with no HTLCs and when it came back up, 7 of my channels disappeared, and every single one of them was an LND initiated force close
Nostr.band is not a Nostr client
Npub.pro is also not really a Nostr client (CMS that pulls from Nostr)
Nos2x is a Nostr signing extension not a client
Amber is a remote signer not a client
Zapplepay is an external service
Nostrame is not either
looking for a good dedicated server host in Europe with BGP and a 10Gbps uplink
You will consume the Primal and VC propaganda and you will be happy nostr:note1y3vatxdv9u8le9yh9l33twtl00yzt37ejxz4g563r9y88xuxqsqq5dyck4
yes, we’re having some discussions on there about gitcitadel relays with the rest of the team
I’d want to get a proper sync spec drafted out that works across any relays