Post Ab5gJsajkOBPK6bJPk by ton@m.tzyl.eu
(DIR) More posts by ton@m.tzyl.eu
(DIR) Post #Ab4ABq8Zb4DvhgaeMi by tante@tldr.nettime.org
2023-10-23T15:43:21Z
0 likes, 0 repeats
I like ActivityPub and the decentralized social Web as much as the next person but we all know that scalability is a massive problem and I haven't seen too many convincing approaches to fix that. So let's not pretend this is just a magic silver bullet.Blogs and the web didn't scale to actual web traffic (which admittedly many blogs never needed), centralized caches and services were necessary for this stuff to work. Which is exactly why we got so much centralization. Solving that for decentralized social networks is the core issue.
(DIR) Post #Ab4AxZ1SX3ieWV1Faa by benni@social.tchncs.de
2023-10-23T15:51:52Z
0 likes, 0 repeats
@tante some of these scalability problems are actually features. The attempt to build one social network for everybody is dommed for failure not for technical but for social reasons.
(DIR) Post #Ab4BGio4NatiMztKee by benjohn@todon.nl
2023-10-23T15:55:28Z
0 likes, 0 repeats
@tante torrent like solutions seems to scale okay? If huge numbers of people follow someone that’s a huge number of possible peers able to repeat a (signed) message? Or many more problems than that?
(DIR) Post #Ab4BMNAril6113FTmK by luis_in_brief@social.coop
2023-10-23T15:55:40Z
0 likes, 0 repeats
@tante Lot to unpack there, especially around scale for who/what.Something I’ve been trying to articulate, but failing so far: when is a distributed network “big enough”, and can UI/UX nudge towards a stable equilibrium around that?Because so far it seems to me that a lot of Twitter→Fediverse migration angst is about expectations, including/especially around “if not web-scale, then bad”. I feel surprisingly happy with a *not* web-scale community, but not everyone does.
(DIR) Post #Ab4BeUj4NmiteKt9VI by tante@tldr.nettime.org
2023-10-23T15:59:38Z
0 likes, 0 repeats
@luis_in_brief smaller (not web-scale) communities are great!But building @hypebot I got complaints by people whose instance got overwhelmed when my small bot with a few 100 followers picked up one of their posts. The fact that the fediverse often runs on smaller hardware is cool when it comes to allowing more people to participate actively but it's also very brittle.And when an innocent bot doing an RT of one of your posts kills your whole instance for an hour or two (taking all other users of that instance "offline" as well) that's affecting participation and access very negatively
(DIR) Post #Ab4BiyKYFuIGcnYUsq by tante@tldr.nettime.org
2023-10-23T16:00:27Z
0 likes, 0 repeats
@luis_in_brief (but I absolutely agree that "being as big as $VC_FUNDED_SOCIAL_NETWORK shouldn't be our yardstick for success)
(DIR) Post #Ab4BsnfWkZvgSD3Ld2 by FinchHaven@sfba.social
2023-10-23T16:02:19Z
0 likes, 0 repeats
@tante I really don't know how often we need to go down this path, but here we go again#Activitypub is a #W3C specificationIt is not an implementation, it is not code, it is not an "app"#Mastodon, an Activitypub --> based <-- software implementation in executable code, current is run on some 12,040 Active ServersHere: https://fedidb.org/software/mastodonHow "decentralized" do you need to be?
(DIR) Post #Ab4BxOJOSEZBG5tCCG by tante@tldr.nettime.org
2023-10-23T16:03:07Z
0 likes, 0 repeats
@FinchHaven I am talking about scalability issues built into the protocol
(DIR) Post #Ab4CDC5RfrhxycttVw by FinchHaven@sfba.social
2023-10-23T16:06:01Z
0 likes, 0 repeats
@tante Said protocol being currently implemented on some 12,040 Mastodon serversWhich is only --> one <-- #Fediverse Activitypub implementatonAgain, how "decentralized" do you need to be?
(DIR) Post #Ab4CMBJttXEMCkwnsO by luis_in_brief@social.coop
2023-10-23T16:07:15Z
0 likes, 0 repeats
@tante @hypebot Yeah, fair! Brings back memories of slashdotting. To some extent I wonder whether the transition away from self-hosted web pages to more centralized services was really about scale, though—very few slights, overall, got slashdotted. In contrast, every single web page admin had to deal with what a pain in the neck self-hosting was. Masto seems, if anything, even worse in difficulty-of-administration than it does in performance.
(DIR) Post #Ab4Ca6f013t3o6SL4q by tante@tldr.nettime.org
2023-10-23T16:10:10Z
0 likes, 0 repeats
@luis_in_brief @hypebot oh yeah, I wouldn't ever run my own masto. Either a simpler more future-proof stack that's less of a pain or pay someone to do it. And I run my own email, matrix and web servers, I am used to pain.
(DIR) Post #Ab4CpWkNJCE33cK8BM by luis_in_brief@social.coop
2023-10-23T16:12:12Z
0 likes, 0 repeats
@tante lol/sob
(DIR) Post #Ab4CyRNSdrTn0gr8k4 by luis_in_brief@social.coop
2023-10-23T16:09:18Z
0 likes, 0 repeats
@tante @hypebot Hypo: what would a world where home hosting an Android-like device *with Android-app-like ease-of-management* and (ideally) easy “pay for CDN if you need it” was the norm? The folks who tried to do something like that a decade ago saw Debian as the “ease of management” target, and that was doomed to fail.
(DIR) Post #Ab4CyS2aAyNB4E5yq0 by tante@tldr.nettime.org
2023-10-23T16:14:35Z
0 likes, 0 repeats
@luis_in_brief @hypebot it's an interesting idea. On the one hand I also like the idea of services that are not available 24/7 but that's no longer the expectation. But introducing an proxy/cache/CDN might sound like defeating the self-hosting thing a bit. And are we okay with people running many unpatched instances everywhere? It's a hard problem. I'm not saying that "every scrappy website needs to be as fast and robust as google.com" is a reasonable thing we taught people to expect. It's absolutely toxic. But it's gonna be hard to form an attractive counter-narrative.
(DIR) Post #Ab4DOGhgwtwrR3dP3A by luis_in_brief@social.coop
2023-10-23T16:19:02Z
0 likes, 0 repeats
@tante @hypebot Yes, this is probably more of an alternate timeline (“what if late-90s Apache had had a UX team” or “what if late-90s Mozilla had devoted as many UX resources to servers as it did to browsers”) than a reality we can get to from the current moment.Re expectation of 24/7, you might enjoy http://solarprotocol.net
(DIR) Post #Ab4DcC5ysZ9nCIdUDw by tante@tldr.nettime.org
2023-10-23T16:21:26Z
0 likes, 0 repeats
@luis_in_brief @hypebot I know Solarprotocol, as someone working in media art I love things that break the medium they use and its connected assumptions
(DIR) Post #Ab4EDxHyNUjMHPFcQa by tante@tldr.nettime.org
2023-10-23T16:28:37Z
0 likes, 0 repeats
@benni when building @hypebot I quickly got complaints how my bot with a few hundred followers would knock people's servers unusable for hours. Like the line where shit breaks isn't "near google scale", it's oftentimes slightly after "running stuff on a raspberry pi scale".
(DIR) Post #Ab4IuZkKBVODX35g92 by washiphil@mastodon.social
2023-10-23T16:55:19Z
0 likes, 0 repeats
@luis_in_brief @tante @hypebot I would love to see that. I've been thinking for a long time about a kind of homepod on which a user hosts everything, from contacts to social, either themselves or in collaboration with others. Of course, the technical hurdle must be as low as possible.
(DIR) Post #Ab4IuaeKpGC0KlIPRo by tante@tldr.nettime.org
2023-10-23T17:21:08Z
0 likes, 0 repeats
@washiphil @luis_in_brief @hypebot I mean that was basically the idea of Solid project https://solidproject.org/ though I think they'd implement the data on your pod but for example feed generation potentially on external more scalable platforms. But from what I see there isn't really much interest in Solid.
(DIR) Post #Ab4L7e9fIv1SsWIuSe by benni@social.tchncs.de
2023-10-23T17:45:51Z
0 likes, 0 repeats
@tante maybe it would be just a good idea to block bots if you run your server on a raspberry pi? @hypebot
(DIR) Post #Ab4LYURbW45ka1UjRY by markhughes@mastodon.social
2023-10-23T17:50:42Z
0 likes, 0 repeats
@tante I'm not sure that makes sense.You only need to handle that traffic because the services became centralised. If self hosted blogs etc had remained at the forefront it would have scaled fine.Agree that fedi isn't the answer, but it's not because it can't scale, it's for the same reason the web was centralised. Because it relies on services which are hard to self host.This is why I support fedi but put my effort into p2p. Eliminate servers and you make centralisation much, much harder.
(DIR) Post #Ab4QbsLjaoMXMQBOr2 by tante@tldr.nettime.org
2023-10-23T18:47:20Z
0 likes, 0 repeats
@benni @hypebot I don't know if the block triggers that. My bit has all tags but it's just doing a repost pushing it to a bunch of different servers. The same would apply if I repost a random thing I see with the almost 10k followers I have here.
(DIR) Post #Ab4QhhtZNGvYftn1DE by washiphil@mastodon.social
2023-10-23T18:48:24Z
0 likes, 0 repeats
@tante @luis_in_brief @hypebot Yes, that's more or less what I mean, with the explicit use case of also storing private data and an all-in-one app that mirrors it on your phone, i.e. a native provider of contacts/calendars etc. for Android for example. I think I stumbled across this years ago, but dismissed it.
(DIR) Post #Ab4RAfTnR1Sla3XnO4 by washiphil@mastodon.social
2023-10-23T18:53:37Z
0 likes, 0 repeats
@tante @luis_in_brief @hypebot Just out of interest, because I am implementing my own ActivityPub server: What exactly is overloading smaller instances? Sure there is some overhead in distributing the information, but with shared inboxes and proper http caching I wonder what exactly is happening?
(DIR) Post #Ab4RzK5cinSE0fOLI0 by kami_kadse@don.linxx.net
2023-10-23T19:02:47Z
0 likes, 0 repeats
@tante @benni @hypebot this doesn't sound like a "we need centralization"-type-problem, this sounds like either a "oops, what should be a personal instance outgrew its resources"-type-problem or a "lets do bottleneck-hunting for a couple of day"-type problem
(DIR) Post #Ab4Tb31Uisyw2M0qlk by festal@tldr.nettime.org
2023-10-23T19:20:42Z
0 likes, 0 repeats
@tante I think decentralized on the protocol level but semi-centralized on the Infrastructure level makes sense. Running any web server from a raspberry makes no sense in the current internet (except when downtime is part of the project, which I totally appreciate). And Mastodon wasn't designed for resourcefulness. Pooling resources is more useful than strict DIY.
(DIR) Post #Ab4TfP3GlMpZW2v51M by tante@tldr.nettime.org
2023-10-23T19:21:13Z
0 likes, 0 repeats
@washiphil @luis_in_brief @hypebot if your small server needs to push out a post to a bunch of other servers at once it can overload the capacity, especially when those servers or their users start instantly at the same time to load assets, query extra data etc.
(DIR) Post #Ab4TqCiAz43oQeChA8 by tante@tldr.nettime.org
2023-10-23T19:23:30Z
0 likes, 0 repeats
@festal I agree. Especially with attached processes for collective governance and rulemaking. But it is something beyond mere technical Implementation that is deeply connected to it though.
(DIR) Post #Ab4XBz4weOX4Nfvm7c by washiphil@mastodon.social
2023-10-23T20:01:04Z
0 likes, 0 repeats
@tante @luis_in_brief @hypebot Hm okay, I don't know how well Mastodon supports that, but as Assets and most of the ActivityPub Objects are quite static, shouldn't a proper proxy cache be able to take off most of the incoming load? I mean with all the heavy stuff that mastodon requires anyway, the servers can't be too small or am I wrong? Might be a problem if signatures are required for all GET requests as well though.
(DIR) Post #Ab4alcoRDGaHbvtdGC by the_duke@social.in-purple.de
2023-10-23T20:41:11Z
0 likes, 0 repeats
@tante @luis_in_brief @hypebot Could part of that be met by something like voluntary relay nodes? Basically like exit nodes for Tor or snowflake relays for Signal? Someone with lots of bandwidth willing to “donate” parts of it to the network. A low power instance pushes a request once to a list of known nodes who then distribute to the myriads of user requests that might otherwise overload the instance.Just spitballing here obviously in an attempt to avoid full on recentralisation a little.
(DIR) Post #Ab4cOhEIp8QAYgBlVw by festal@tldr.nettime.org
2023-10-23T20:58:46Z
0 likes, 0 repeats
@tante Absolutely. Nothing in tech is ever "only" technical.
(DIR) Post #Ab4cSahj1k9dTioAKm by tante@tldr.nettime.org
2023-10-23T21:00:01Z
0 likes, 0 repeats
@festal Now don't make the nerds angry ;)
(DIR) Post #Ab4e4tXTY4B0qqqIGu by bituur_esztreym@pouet.chapril.org
2023-10-23T21:18:04Z
0 likes, 0 repeats
@tante @festal but why would the nerds get angry? they too are humans, zoon politikon.. #ohwait `w;7[)#illgetmycoat
(DIR) Post #Ab5XGMafN4FzcKofuS by ton@m.tzyl.eu
2023-10-24T07:36:04Z
0 likes, 0 repeats
@tante "Blogs and the web didn't scale to actual web traffic" : what do you mean by that?
(DIR) Post #Ab5XwumadRFRpEgRk0 by tante@tldr.nettime.org
2023-10-24T07:44:18Z
0 likes, 0 repeats
@ton I am old enough to still remember when "slashdotting" or "Neil Gaiman linking to your page" would take most pages offline for hours. People then added cloud flare or moved to a hosted version that did the scaling because the "run your own blog" scenario didn't scale to what _can_ happen on the web
(DIR) Post #Ab5gJsajkOBPK6bJPk by ton@m.tzyl.eu
2023-10-24T09:18:07Z
0 likes, 0 repeats
@tante Ah, I see what you mean. But that's not a scaling issue per se right, as the need for scale is tied to specific types of asymmetric risk. Those that see that risk as common will plan for higher traffic (cloudflare etc). Those that don't will plan for intermittency more, given how they view their audience. (i've blocked specific URLs in the past that peaked in traffic for a while e.g.). Why would one expect to cover all eventualities?
(DIR) Post #AcbaHJRjh5ggKU4gu8 by evan@cosocial.ca
2023-12-08T16:33:10Z
0 likes, 0 repeats
@tante tell me about the scalability problems.
(DIR) Post #AcbbCN7sgY1UFRzn9c by tante@tldr.nettime.org
2023-12-08T16:43:34Z
0 likes, 0 repeats
@evan I run @hypebot which isn't huge but still can knock small instances offline should a post find its way into the bot. If you have a beefy server it probably works (like mastodon.social) but especially smaller instances can really hurt when they become popular. The of course there's the side effects of every instance someone follows you on ddosing your blog should you post an article in order to get a preview/link card. Networks can unintentionally create a lot of load and the answer obviously shouldn't be "just be on mastodon.social" or "pay 50 bucks a month" for your own private instance that can survive the traffic
(DIR) Post #AcbbxVbKzbmq8yFZk8 by thisismissem@hachyderm.io
2023-12-08T16:52:05Z
0 likes, 0 repeats
@tante @evan @hypebot I'm wondering if even in a federated world we can have some sort of centralised caches?e.g., you configure your instance with a list of preview caches you trust, and it'll grab the previews from them, rather than going directly to the original server. The current approach the Mastodon core team seems to want to take is to embed the preview in the post, but refetch if they get another preview for the same URL, idk if this is a good approach.
(DIR) Post #AcbcAOxyyJeVKZzRT6 by tante@tldr.nettime.org
2023-12-08T16:54:23Z
0 likes, 0 repeats
@thisismissem I think embedding the preview card is a very good first approach.
(DIR) Post #AcbeQ8LajGwMKSf7Ue by evan@cosocial.ca
2023-12-08T17:19:38Z
0 likes, 0 repeats
@tante @hypebot So, for previews, absolutely correct. The sending server should generate the preview once; it shouldn't be generated thousands of times on many clients. We should probably be using the `Page` or `Link` types in ActivityPub rather than just including the links and expanding them on the client.Could you explain the other part? I don't think boosting a post should generate any traffic for the originating server. Is that what happens?
(DIR) Post #AcberndzITg8E9SWlk by thisismissem@hachyderm.io
2023-12-08T17:24:33Z
0 likes, 0 repeats
@tante the problem with it is that you must trust the embedded data, which caused bluesky problems (folks masking malicious or nefarious links with other preview card details)So you really want a "trust but verify" model
(DIR) Post #Acbf4vPFkRYa4ApFoW by tante@tldr.nettime.org
2023-12-08T17:26:59Z
0 likes, 0 repeats
@evan it wasn't my server so I couldn't debug. My guess is that the profile data and avatar image lookups killed the server (which probably was a very small box)
(DIR) Post #AcbffBCCWKq3Sg0ZZQ by evan@cosocial.ca
2023-12-08T17:33:28Z
0 likes, 0 repeats
@tante oh, interesting. That should happen about once per receiving server, so it shouldn't be that big of a hit, but I can see having it be a problem if it all happens at once. Exponential backoff should help, though. That said, I think we should have a way to specify a content-addressed fallback for binary data, like IPFS.
(DIR) Post #AcbgSv7YYpaA5LYPUu by thisismissem@hachyderm.io
2023-12-08T17:38:43Z
0 likes, 0 repeats
@evan @tante that and it's just good practice to use a CDN.. which will help with cacheable content — I see a lot of folks wanting to run fediverse instances on raspberry pi's in their home, without any network caching or DDOS protection
(DIR) Post #AcbgSwKi3PhJqQiQdc by evan@cosocial.ca
2023-12-08T17:41:05Z
0 likes, 0 repeats
@thisismissem I think @tante is talking about scalability at the small end of the scale, though.
(DIR) Post #AcbgSx4RJOHG8G6wuu by tante@tldr.nettime.org
2023-12-08T17:42:33Z
0 likes, 0 repeats
@evan @thisismissem exactly. Small servers get hurt a lot by traffic many boxes might not even feel. But it takes people's identity and digital social existence offline which is really bad
(DIR) Post #AcbglGdnHxxG2aNi6K by thisismissem@hachyderm.io
2023-12-08T17:45:53Z
0 likes, 0 repeats
@tante @evan I suspect that's where something like having an external inbox service might help?Such that you've still got an inbox, but rather than folks hitting your server directly they hit a middle service that can adjust the load to what your server can handle
(DIR) Post #Acbh2Tw76rbMCO9uIC by tante@tldr.nettime.org
2023-12-08T17:48:56Z
0 likes, 0 repeats
@thisismissem @evan maybe. But of course this creates vectors for centralization as well as more potential attack vectors reading your "private" messages. I always feel that Mastodon kinda wants you to have a ideally direct sort of relationship of trust to your admin team to keep your data safe and not snoop. More 3rd parties isn't helping in that regard.