hachyderm.io is one of the many independent Mastodon servers you can use to participate in the fediverse.
Hachyderm is a safe space, LGBTQIA+ and BLM, primarily comprised of tech industry professionals world wide. Note that many non-user account types have restrictions - please see our About page.

Administered by:

Server stats:

9.7K
active users

Brad L. :verified:

I'm floored by how inefficient is as a protocol. Was it invented in a vacuum absent the decades of learning about handling data at scale?

I love the , but ActivityPub is a massive stumbling block to its own success at this point.

Simple example, if 500 people follow you on 2 instances, when you "toot", your server sends 500 messages.

Unfortunately, no amount of or is going to save us from the inherent scaling deficiencies of the protocol itself.

I've seen an explosion of and projects to simplify the operations nightmare that is running a instance. I'm glad that work is being done.

But to use an idiom I recently learned, that's building a pedestal instead of training the monkey to juggle. It doesn't matter how many statically compiled, self-contained instances (pedestals) we have if we need 10Gbps+ on real-time kernels on those instances because of the underlying protocol inefficiencies (juggling monkeys).

@reyjrar certainly there's a... reason?

@frob @reyjrar Is it me or is simply not described how the server should identify who to address the sharedInbox message to? Or do the receiving servers need to have shared inboxes defined per batch? That is pretty bad batching

@reyjrar

The #ActivityPub spec has a mechanism for addressing this w3.org/TR/activitypub/#shared- but I've not done any dev work with ActivityPub, so I don't know how well it works in practice.

> For servers hosting many actors, delivery to all followers can result in an overwhelming number of messages sent. [...] a server MAY reduce the number of receiving actors delivered to by identifying all followers which share the same sharedInbox [...] and instead deliver objects to said sharedInbox.

www.w3.orgActivityPubThe ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

@reyjrar it’s bad tech, and I am not too happy about the decisions of the people behind it to censor nodes which implement ingress filtering like Counter Social. Mastodon is not my first choice but seems like where people I like want to talk in a post-Twitter world, despite all of its flaws

@reyjrar If the gnutella protocol is any indication, vendors will fix most of the problems... each in an incompatible way and then refuse to interoperate with each other except for a few bits and pieces. Then someone named Mike will come along and claim to have a v2 of the protocol that's worse than v1.

@reyjrar is there a technically better alternative? Because #mastodon seems to be working fine on the #socialnetwork front, it might be interesting to think about enabling the underlying technology for the growth to come.