can't use cloudfront or aws will go down. can't use cloudflare or else it will go down. maybe we need better CDN tech

Replies (40)

we just need intelligent caches. for example: an LRU cache at the network layer + a content addressable internet. nostr is a tiny glimpse of this: we can negetropy-sync notes from local network nodes without needing to hit the wider internet. something we're just starting to do at damus.
𓊽's avatar
𓊽 1 month ago
yeah it does 😆
yeah icn/ccnx/ndn all good ideas. probably too complicated to implement in our lifetimes though. maybe will always be vaporware.
It was mostly tongue-in-cheek. For small shops it’s not practical, but there definitely is a problem in that large shops with 1k+ employees don’t bother self-hosting anymore. Makes the internet so brittle…
as long as we make our solutions simple to run and maintain. i like the "lightning app" idea... where as a business all you really need is to run a lightning and bitcoin node, then you access the node over lightning to provide services (like the notedeck_clndash app or ) this is way easier than setting up and maintaining web and email servers.
If I can self-host a global anycast caching proxy network with multiple upstream as a side hobby with a full-time job, I think most companies with 100+ people can too. Or at least bother with redundant CDNs…
I don’t think this is a “web and email” problem. It’s a “we can cut costs by leaning on cloudflare/AWS’s competence so we don’t need any competence in house” problem. If you have 100+ employees, you should be self-hosting much of your infra (or multi-cloud’ing it if you really don’t care about data security) and have redundant CDNs you can switch between if cloudflare is down.
my point was we don't actually need the web for many use cases. could all just be RPC calls over lightning for business stuff. once we can get rid of the server requirement, we can start building nostr and lightning client apps that connect to self hosted nodes in a way that wouldn't require you to run a VPS for everything. maybe this is just a fantasy land dream of mine
The first two are pretty basic skills. The third one might prove to be difficult, since mammoth are extinct 😅 (yes, I know you were joking)
Sure, but that’s the problem. It’s not super hard (not trivial, I don’t expect startups to do it, but if you have 100 employees?), but no one bothers to do it anymore, so it’s not something anyone needs to learn/teach. Even worse version is DNS - many web engineers feel like DNS is scary, despite it being easier to handle in nearly every way than HTTP (easier to make redundant, easier interoperability between servers, easier to configure, etc).
Yea, getting mobile off of servers and onto the client is a whole other ball of yarn. Sadly one even harder than self-hosting, but maybe more important.
"Interesting perspective! While self-hosting has its merits, leveraging cloud solutions can also drive innovation and agility. It’s all about finding the right balance for your team's needs and goals. 🌐✨ #TechStrategy"
Playing devil's advocate, I wonder how many of these services that utilize AWS/CloudFlare really need their services. I bet most are on board for the ecosystem and not truly for their HA.
directly related to something else I said today: server and bandwidth burden shouldn't all be on one entity. here we are swimming in nearly decentralized waters yet there are these glaring centralization points whose tradeoffs mean "sometimes one service farts and an entire user experience disappears for a while". I refuse to accept that long-term.
vinney...axkl's avatar vinney...axkl
I am something of a true p2p jihadist, so it makes sense we'd be far apart on this. I think it's a natural step in the decentralization, voluntarism and subjective-ication of everything. The timeline: 0. today. (standard client/server web with lots of intermediaries that are hard to exit while preserving desired utility) 1. decentralized, subjective contextual webs of trust (same physical/networking infra, but the lines begin getting drawn - by the participants themselves - **conceptually**/in code for voluntary islands of trust) 2. sovereign personal servers that you can fully trust; and connect to from edge devices (on an individual level, you own the full stack of client/server, but the servers still deal with lots of intermediaries and ISPs between each other) 3. personal servers that connect peer to peer directly based on contextual WoT (servers connect directly to each other, using WoT as their peer discovery and network topology guidelines. individuals' very light edge devices rely more and more on their sovereign personal server which connects directly to the servers of others) 4. mesh networks slowly overlay on top of ISPs and gradually replace them (those same p2p personal servers can connect directly over local mesh when a route is found. ISP censorship and infrastructure flakiness becomes irrelevant in these contexts. some problems may still exist in intra-mesh connections) 5. the lines drawn at step #2 are now fully realized in the physical infrastructure and network topology of very many overlapping voluntary networks and trust islands. people are free to re-jigger these physical and/or conceptual arrangements as needed. The end state being high-trust networked communities and economic zones that are truly antifragile and nearly impossible for a centralized enforcer to disrupt or censor short of enormous kinetic violence.
View quoted note →
The cost in a radically decentralized setup like this will be much higher than what a centralized entity can provide today. That is always the case with decentralized systems. They are slower and more costly than centralized ones, but more robust.
We don't need CDNs, we just need to improve browser support for torrents. A website publishes a nostr event to a bunch of nostr relays, including their own, including magnet URLs (or realistically just file hashes), for every asset they need a CDN for. Cloudflare can go down and the website will be up. The website can get DDOS'd and it gets faster
the global cost is also spread across millions of entities. no single party has to provide and maintain service to "everyone else". the gain in robustness is exactly proportional to the distribution of cost. that's not even discounting the enormous costs (from technical to privacy to 'spiritual') to the end users that come smuggled along with the "savings" a centralized entity offers