Possible Membership Tiers for Fediverse Servers
-
Raphael Lullisreplied to Scott M. Stolz last edited by [email protected]
I think the key question I'd have is the one you are still figuring out the answer: given a deployment of a hubzilla server with a configuration, how many users can you serve?
E.g, how small is the $6/month "small instance"? Can it work with 10 users? 100? 3? And what happens when the average user follows 100 other people on the Fediverse? And what happens if one of these users follows a bunch of media heavy content? What would happen if one popular user is followed by 2M people?
-
@Raphael Lullis Another goal is to offload users with heavy usage onto their own servers. This makes costs more predictable and also aligns with our goals to decentralize social media. It also means that they get administrator access to their own servers, and can configure it how they want.
So when I say a stretch goal of 1 million, I don't want all of them on the same server. I mean total Hubzilla users, some on our flagship servers, some using our @TechSero hosting, some using other hosting providers like @K&T Host , and some self-hosting at using @YunoHost.
The goal is to create an ecosystem that attracts users but also promotes decentralization. -
@Raphael Lullis Another goal is to offload users with heavy usage onto their own servers. This makes costs more predictable and also aligns with our goals to decentralize social media. It also means that they get administrator access to their own servers, and can configure it how they want.
So when I say a stretch goal of 1 million, I don't want all of them on the same server. I mean total Hubzilla users, some on our flagship servers, some using our @TechSero hosting, some using other hosting providers like @K&T Host , and some self-hosting at using @YunoHost.
The goal is to create an ecosystem that attracts users but also promotes decentralization. -
@Raphael Lullis That is the tricky part. Usage by users vary greatly.
A small instance starts at $5.95 with 2 GB RAM, 20 GB of space, and 100% CPU, which gives you 50 processes. For $1 more, you can upgrade to 200 GB of disk space.
Based on usage on existing servers, that is sufficient for dozens of channels with average usage, or 1 user with very high usage. It probably could handle much more, but most of the servers we have as examples have less then 12 users on them, so we don't know the maximum it can hold.
This might be a good idea for a test. I can set up one of our servers and clone a bunch of accounts on it, and see how it fares. -
@Raphael Lullis That is the tricky part. Usage by users vary greatly.
A small instance starts at $5.95 with 2 GB RAM, 20 GB of space, and 100% CPU, which gives you 50 processes. For $1 more, you can upgrade to 200 GB of disk space.
Based on usage on existing servers, that is sufficient for dozens of channels with average usage, or 1 user with very high usage. It probably could handle much more, but most of the servers we have as examples have less then 12 users on them, so we don't know the maximum it can hold.
This might be a good idea for a test. I can set up one of our servers and clone a bunch of accounts on it, and see how it fares. -
FYI: each reply from you is generating multiple repeated responses, (presumably) one for each identity you have set up?
-
Yeah, you definitely need to synthesize some type of benchmark. There is no other way to answer the question "what do you think of this pricing strategy?" if you have no idea about your costs.
If you'd like to have some kind of load test, maybe you could set up an instance that mirrors 100k random active Instagram accounts and see what happens both with your instance and the network?
-
@Raphael Lullis
FYI: each reply from you is generating multiple repeated responses, (presumably) one for each identity you have set up?
That is because ActivityPub does not support nomadic identity (although there is an FEP for it). As such, Mastodon does not realize that all of those are the same channel and the same post.
This is one benefit of Hubzilla and Zot Protocol. You can clone your channel on as many servers as you want, but users will only get one copy of all of your posts, and also will be notified of your primary server.
My primary channel is [email protected] and I would recommend following that one. You can unfollow all of the others since they are duplicates or clones of [email protected].
Until ActivityPub and Mastodon recognize nomadic identity, this will continue to be an issue, unfortunately. -
@Raphael Lullis
FYI: each reply from you is generating multiple repeated responses, (presumably) one for each identity you have set up?
That is because ActivityPub does not support nomadic identity (although there is an FEP for it). As such, Mastodon does not realize that all of those are the same channel and the same post.
This is one benefit of Hubzilla and Zot Protocol. You can clone your channel on as many servers as you want, but users will only get one copy of all of your posts, and also will be notified of your primary server.
My primary channel is [email protected] and I would recommend following that one. You can unfollow all of the others since they are duplicates or clones of [email protected].
Until ActivityPub and Mastodon recognize nomadic identity, this will continue to be an issue, unfortunately. -
> As such, Mastodon does not realize that all of those are the same channel and the same post.
I'm usually quick to point fingers at Mastodon, but I'm not sure if this time they are at fault.
Mastodon (and most of ActivityPub current server software) does push-based interop. This means that any notification that I receive corresponds to one different activity being POST'ed to my actor inbox.
I'm not familiar with ZOT, but I'd be curious to know what is causing this.
-
@Raphael Lullis It is a known incompatibility issue. It has to do with how each platform handles aliases (or doesn't).
Hubzilla uses something called the Zot protocol, which is basically our version of ActivityPub. It supports certain things that ActivityPub does not support, which is why we still use it.
In Hubzilla and Zot Protocol, I can have clones (duplicates/aliases) of my channel. So [email protected] and [email protected] reside on different servers and are constantly synced. If one server goes down, I can log into the other. If I want to move servers, I can. Since Hubzilla and Zot allow cloning, they also recognize cloned accounts. They know these two accounts are the same account.
But, Mastodon and ActivityPub do not support this feature. ActivityPub thinks that [email protected] and [email protected] are two different accounts. So if you follow both of them, you get the message twice in Mastodon.
For ActivityPub followers, we have to send out copies of posts from all of the clones, because some people may follow one clone, and other people may follow another. This ensures that someone following an old but active clone can still get our posts. We are assuming that most people would follow only one clone and perhaps don't even know about the other clones.
Hubzilla does announce that these are cloned channels (aliases) via Webfinger, but to my knowledge, no ActivityPub platform checks this and none use this information to suppress duplicate posts.
It really isn't about blame. It is just that Mastodon does not support nomadic identity, so you get weird things like this. -
@Raphael Lullis It is a known incompatibility issue. It has to do with how each platform handles aliases (or doesn't).
Hubzilla uses something called the Zot protocol, which is basically our version of ActivityPub. It supports certain things that ActivityPub does not support, which is why we still use it.
In Hubzilla and Zot Protocol, I can have clones (duplicates/aliases) of my channel. So [email protected] and [email protected] reside on different servers and are constantly synced. If one server goes down, I can log into the other. If I want to move servers, I can. Since Hubzilla and Zot allow cloning, they also recognize cloned accounts. They know these two accounts are the same account.
But, Mastodon and ActivityPub do not support this feature. ActivityPub thinks that [email protected] and [email protected] are two different accounts. So if you follow both of them, you get the message twice in Mastodon.
For ActivityPub followers, we have to send out copies of posts from all of the clones, because some people may follow one clone, and other people may follow another. This ensures that someone following an old but active clone can still get our posts. We are assuming that most people would follow only one clone and perhaps don't even know about the other clones.
Hubzilla does announce that these are cloned channels (aliases) via Webfinger, but to my knowledge, no ActivityPub platform checks this and none use this information to suppress duplicate posts.
It really isn't about blame. It is just that Mastodon does not support nomadic identity, so you get weird things like this. -
@scott but shouldn't it be possible for Hubzilla to track who-follows-what, and only send the messages accordingly?
I surely don't follow you from your other identities. Maybe Hubzilla could have a system that sends messages only with as:Public by default, and only addresses the responder with the "in reply to" field by the follower's known aliases?
-
@Raphael Lullis Hubzilla does track who follows what. If you follow [email protected], only loves.tech will send you the message. The other clones do not send a message to you.
But Mastodon has a shared inbox. And there are other people on your server who may be following the other clones.
So what might be happening is that you follow [email protected] so loves.tech sends you a copy of the post. But someone else is following [email protected] so authorship.studio is sending them a copy of the post. They both go into Mastodon's shared inbox on your server, one addressed to you, one addressed to them.
Mastodon does not realize that this is the same post and same user, so it adds both copies of the post to the conversation.
At least, that is my theory on what is happening. -
@Raphael Lullis Hubzilla does track who follows what. If you follow [email protected], only loves.tech will send you the message. The other clones do not send a message to you.
But Mastodon has a shared inbox. And there are other people on your server who may be following the other clones.
So what might be happening is that you follow [email protected] so loves.tech sends you a copy of the post. But someone else is following [email protected] so authorship.studio is sending them a copy of the post. They both go into Mastodon's shared inbox on your server, one addressed to you, one addressed to them.
Mastodon does not realize that this is the same post and same user, so it adds both copies of the post to the conversation.
At least, that is my theory on what is happening. -
I'm getting really closed to get nerd-sniped by this and set up a database viewer to see who-is-following-who on the server.
-
@Raphael Lullis One of the reasons why they set it up this way is because of how Mastodon notifications work. If you follow [email protected] but [email protected] sends you the message, Mastodon will not notify you of the message. It has to be sent from the account and domain being followed.
So if two people follow different clones, the only way Mastodon users will be notified is if we send it from both clones.
But, apparently, this means in conversation view, there would be two copies of the post. Or more than two in this case.
Basically, that is the issue. We send on copy, Mastodon notifications don't work. We send multiple copies, Mastodon notifications work, but you may get duplicate posts. -
@Raphael Lullis One of the reasons why they set it up this way is because of how Mastodon notifications work. If you follow [email protected] but [email protected] sends you the message, Mastodon will not notify you of the message. It has to be sent from the account and domain being followed.
So if two people follow different clones, the only way Mastodon users will be notified is if we send it from both clones.
But, apparently, this means in conversation view, there would be two copies of the post. Or more than two in this case.
Basically, that is the issue. We send on copy, Mastodon notifications don't work. We send multiple copies, Mastodon notifications work, but you may get duplicate posts. -
Marshall Sutherlandreplied to Scott M. Stolz last edited byIf Alice and Bob are on different servers, obviously any messages between them would be on both servers, but if they are on the same server, do they share the messages in the database or do they each have their own copy? If the messages are shared, it seems like this could make fewer, larger servers more space-efficient than more, smaller servers.
Another scalability question comes to mind... Can you have multiple web servers for the same Hubzilla database (not a single database server with multiple Hubzilla databases)? -
Scott M. Stolzreplied to Marshall Sutherland last edited by@Marshall Sutherland A single large server would be more efficient, in the terms of resources, however, there are other considerations.
First, we have the goal of decentralizing social media, so multiple smaller servers run by different administrators achieves that goal.
This encourages the creation of unique communities with their own cultures and community standards. This avoids the problem of moderators unfamiliar with another culture moderating content unfairly due to a cultural or context misunderstanding. It also allows for complete independence when someone runs their own server.
Secondly, it is also a matter of delegating the workload. Each server administrator is responsible for moderation on their own server.
Thirdly, there are different rules for social media and web hosting.
For users on our servers, they fall under social media rules, which requires moderation of content and compliance of various privacy and social media and age restriction laws.
But for web hosting, none of those rules apply to us, the web host. If someone complains, we'll investigate, but the server administrator is responsible for moderating content, not us.
Putting people on their own servers with their own domain name reduces our workload because it delegates most moderation and compliance work to the server administrator.
Another consideration is that costs for smaller servers are more predictable than costs for giant servers.
Although it would be more efficient to have a very large server with millions of people, for legal, technical, and philosophical reasons, we want to pursue decentralization.
Copyright © 2025 NodeBB | Contributors