@Buster Keaton We have to decide whether to run the services in the first place as a part of durare.org project. After we have consensus on running the services, we can decide whether to host them on a new server or the existing one.

@Ravi Dwivedi Ok. I am not keen on running these as part of durare.org project.

Meaning: withstand difficulty or resilience

I don't relate these new services with durare's core meaning.

I'm adding some observations from existing projects, mostly for me to get an idea of the big picture. I have tried not to jump to conclusions in this comment.

Stats from Disroot

Disroot is a similar platform providing privacy-respecting alternatives to corporate "cloud" services and social media. These are the expenses and donations from disroot from 2015 to 2023:

Source: https://disroot.org/en/donate

Converting the costs to INR (using yearly average conversion data), we get:

Source: for url in https://www.exchange-rates.org/exchange-rate-history/eur-inr-20{15..23}; do xdg-open $url; done

While disroot had two people and insufficient funding in the first few years, it gained financial stability in 2018 and had a six member crew by 2020. Also, by 2020, in addition to the FOSS donations, they were able to pay monthly volunteer fees to two members and had a dedicated volunteer by 2021.

Source: Annual reports and https://disroot.org/en/blog/news03-2021

Disroot seems to have survived nine years as of 2024 and is going well, though they haven't reached the financial target for 2024 (please donate if you can). Platforms like disroot and autistici are some of the few non-profits in an area dominated by big tech, and it would be nice if there are more players on the list.

Cost concerns

A federated mastodon instance with 100 active users can take up around 100 GB for media storage and 10 GB for the database. But Akkoma being lightweight does not store federated media by default, and I'm estimating the storage requirements for an instance at around 50 GB with 100 active users. Assuming 100 GB storage each for Pixelfed, loops and PeerTube, and 20 GB each for flohmarkt and Mobilizon, we will need a total of 400 GB storage and probably around 8 to 12 processing threads. If we're using a cloud service to host, it could cost somewhere between ₹ 5,000 and ₹12,000 per month, which translates to ₹60,000 to ₹1,44,000 per year. The actual price will likely be less than this estimate, as it's possible to get extra storage for many cheap VPS plans. This can still be reduced to bandwidth charges and electricity bills if we can find an ISP and hardware and self-host ourselves.

Source: https://masto.host/pricing/ https://docs.akkoma.dev/stable/configuration/storing_remote_media/

Price source: https://www.gandi.net/en/cloud/vps https://www.infomaniak.com/en/hosting/vps-cloud/prices https://www.ovhcloud.com/en-in/vps/vps-india/ https://www.digitalocean.com/pricing/droplets https://www.hetzner.com/cloud https://www.hostinger.in/vps-hosting

Hosting each service independently under a different domain

This might sound tempting, but for people used to big tech "offering" many features under one umbrella, I think providing Akkoma, Pixelfed, Loops, PeerTube, Flohmarkt and Mobilizon under a single domain with SSO would be better initially bring people into the fediverse. Also, I think (but I do not have any data to back it up) providing more services like akkoma and pixelfed will attract more donations than running something like an XMPP server alone.

Edit: fixed unfinished sentence in last paragraph of stats from disroot

@perry my suggestion was not to have one domain each for the services, but a different domain / server for all these services instead of changing durare.org (like how we did with diasp.in). But still both under same community.

Also bandwidth cost would be too high if hosting a physical server in India. We will also need to take care of power reliability, cooling, etc

@praveenarimbrathod I understood that. I was addressing an argument that might arise, that an organisation running many decentralised services under a same login (like LDAP) is antithetical to decentralisation. My wording came out wrong in that comment.

@perry ok, one more point I missed. muppeth and antilopa invested significant time and effort in initial days before they got a lot of donations and bigger team at a later stage. Keep that in mind and if possible talk to them about their time and effort before committing to something like this.

@perry it is not going to be centralized when it is decentralized at the protocol level. Even bundle of many services are provided by many like disroot.org, nixnet.services etc

Adding some more comments on this.

Benefits of offering ActivityPub-based services

• Funding and publicity: I think running an ActivityPub instance would help a lot with funding. We can point to the numerous other instances which operate on the same model, so people will not find it unusual. Also, we will benefit from the generic "fund your instance and instance admins" campaigns that come up every so often.

• Educating people about federation: In my opinion ActivityPub is an easier way to teach people about federation compared to XMPP (or email, SMS, etc.) as we can literally point to the very different implementations and see how they operate ("use your Pixelfed account to comment on a Peertube video!" is all it takes).

• The need for an instance: As mentioned in my vote, I have been seeing posts every so often asking whether there are any instances in India or wondering where to find Indians on the Fediverse.

Challenges and long-term planning

• Initial commitment: I agree with @Pirate Praveen about having some kind of base plan (6 months funding and volunteers, etc.) before we officially launch this.

• Moderation: Moderators in particular are important for Fediverse instances, as many on the Fediverse take moderation very seriously—there have been many cases where instances have defederated from other instances due to finding the moderation not good enough. This also takes diplomatic skills to be able to get along with mods of other instances.

• Cultural knowledge: Anyone who's moderating should also have a decent idea of Fediverse culture and lingo! There is no "universal" culture because we're all on different instances—but at the same time, there kind of is and we should at least be somewhat aware of the politics and different viewpoints there.

• Resource usage: As @Arya K pointed out, AP relays also end up using a lot of space, because literally every post an instance knows about is stored. (I'm not sure if there's some pruning that happens at some point; we need to check the docs of whatever we're planning to install and see how that is handled, if at all). Because of this, it might be prudent to choose a storage-heavy host (like Contabo, which has relatively cheap high-storage VPS plans).

• Limiting signups: Perhaps we should limit the number of signups to a certain amount, and increase it only when we know we have things stable. (Hopefully this will also increase hype like Gmail did 😉). I mean even if we are running on an invite-only bases, we should still cap the number of accounts and increase gradually after making sure we can handle it. Ideally, we should keep some "reserve" to open up during a Fediverse wave (when people get annoyed at some centralised platform and move en masse to a federated alternative)

Technical setup

• Server: Because of AP taking up more resources, I would recommend having it on a different server than the one on which we are running Prosody—for example, the Contabo services I mentioned.

• YunoHost: I would also recommend running these services using something like YunoHost. This gives us less flexibility in setup as it is highly opinionated on how things should be organised. It also takes some time for software updates to show up in YunoHost (we could of course package the newer version ourselves and help the community in the process). However, YunoHost automates a lot of things like domain renewal, monitoring, and taking backups, that we would otherwise have to learn to do manually. I don't think we need a very customised setup for any of these services, so it makes sense to go with the default and let YunoHost handle things.

• Last resort: As a backup plan, there are managed services like masto.host which can handle the hosting for us (for a higher fee) and let us focus on moderation. We can keep this as a worst-case/backup option in case we are not able to handle the tech setup ourselves. I am not sure which other software have similar services, but we can take a look.

A note on ActivityPub

• Just wanted to address a common misconception here regarding ActivityPub. There is no need to have a Pixelfed account and a Mastodon account (for example) to interact with Pixelfed and Mastodon users. You only need one account to interact with all the others. The only reason you'd make different accounts is if you want to showcase your work under different interfaces (eg. Peertube is well suited to running a video channel). There are some cases where a platform has very specific kinds of content (eg. BookWyrm) that may not federate very well with other platforms, but in general you can get by with just one.

• Similarly, there is no need to use only Akkoma apps for Akkoma, etc. For example, Tusky is an app primarily designed for Mastodon, but I have used it to manage my Pixelfed account too. Some apps like Tuba (and I think Fedilab?) are explicitly designed to support multiple Fediverse software. (The caveat with using a different app is there may be a few missing features. And if you try to use a Peertube app for Bookwyrm you're on your own 😉)

• The relevance of the above being we should think about what we (or our users) really want to do and only choose the minimum subset of apps that allows us to do that. For example, instead of Akkoma and Pixelfed, it might be possible to just run GoToSocial and have different frontends for people to showcase their work in different ways.

Questions to consider

• Exactly which services do we want to host (and why)? (@fugata's shortlist is a starting point)

• How many users do we want to start with? (Kev Quirk, one of the Fosstodon admins, recently did an experiment with 500.social)

• How much are our expected costs? (@perry was starting to document this)

• Do we have enough (potential) funders to keep this going?

• Who will be moderating this instance?

• Who is going to do the technical maintenance?

Where I can help

• I can help with deciding what service(s) to start with—ideally just one on a trial basis before we decide to add more. Similarly, I can help with deciding what frontends to set up for that service, if any.

• If we decide to use YunoHost, I can volunteer to monitor the periodic system check and take action if something breaks. In my experience this is usually low disk space, failed cert renewal, impending domain expiry, temporary network issues, or a package being temporarily removed from the YunoHost app store due to being broken. If it's an upcoming domain expiry I can inform the relevant person/group but I won't be actively taking charge of the fundraising.

• I can also help to fix broken packages to some extent (based on my expertise) for the following services if/when we decide to run them: Akkoma, Bookwyrm, possibly Pixelfed. By "help" I mean ideally have one other person also working it out along with me 🙂

• I know some instance admins, so I could talk to them to find out what we're getting into and how much work we can expect to have to put in.

• I can also do a sense check on the Fediverse to see how much interest there is in joining such an instance. If we have active fedizens willing to switch over to (or create an alt on) our server, it will help provide initial activity when convincing other people to join.