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

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.

We've got around 6 volunteers - including @Badri Sunderarajan, @perry, and me - who are interested in setting up these services.

Before we start crowdfunding, we need to know what services we will be running. We've given that a lot of thought, and have divided it into 3 phases -

1. Phase 1 - add primary ActivityPub (AP) services.

   1. Primary ActivityPub services - Akkoma, PixelFed, PeerTube, Lemmy, and Mobilizon. These are the services we expect will be most likely to be used by Indian users.

   2. Primary communication service - XMPP, provided by durare.org.

2. Phase 2 - add cloud services, and secondary communication and AP services.

   1. Cloud services - NextCloud, Cryptpad, Ente and/or Immich, EteSync. (Most of these can also be handled by NextCloud alone. We need to evaluate them.)

   2. Secondary communication services - email, Jitsi Meet and/or BigBlueButton. (Video calling can also be handled by NextCloud Talk.)

   3. Secondary ActivityPub services - Flohmarkt, BookWyrm, Funkwhale.

   4. Live location sharing, e.g. Hauk, or NextCloud Maps, or NextCloud Phonetrack

3. Phase 3 - add some geekier services

   1. a wiki, such as ibisWiki

   2. web hosting

   3. shell accounts (a la Tildeverse)

   4. Forgejo

   5. a Tor exit node

   6. RSS feed aggregation

   7. Sharkey (a fork of Misskey), a featureful, fun, colorful, and highly-customizable federated microblogging platform

   8. A federated short video platform (like TikTok) such as Loops or Vidzy

We could give 6-12 months per phase before we try to advance to the next phase. Of course, it also depends on whether we're able to crowdfund the next phase or not.

Let me also reiterate some critical aims of these services -

1. The site and services should be available in English and Indian languages. As a counterexample, consider how many XMPP and Misskey servers are not available in English, hindering people from trying them out.

2. Easy onboarding. Open registration is a pain because of spam and abuse. While we could still offer manually-approved registration, the primary way to join should be invites.

3. Single Sign-On (SSO). Users should be able to sign in to all services with the same account, making it as seamless as Google or Apple services.

4. Content should be moderated by Indians (who understand Indian languages, cultures, and politics) to prevent hate speech and disinformation (as a counterexample, see Reddit)

While we are about to get a new server for these services (as @Pirate Praveen and @Badri Sunderarajan have recommended), we have two choices for the domain -

1. Make the new services subdomains of durare.org. This provides a consistent experience, and is my preferred way.

2. Use a new domain for the new services. This makes it somewhat inconsistent with the idea of "one account for all services". However, it could allow us to eventually offer all services (XMPP, AP, cloud, email, etc) with a choice of durare.org or the new domain.

Are there any objections or changes suggested to the plan? What does everyone say to the decision about the domain?

(Also agreed with @Ceda EI on using <service>.durare.org for most of them)

@Ceda EI If durare.org lists all services in the homepage with links, that might be enough for people to find all the services at one place. Microsoft is an example where different services have different names (Google generally has same name but even it has gmail and youtube as seperate brands).

I think this needs to be handled on a case-by-cases basis. For smaller services, it makes sense to bundle them, whereas for larger "flagship" services that people might sign up for without using any related ones, we could think of having a separate domain (example given by @Pirate Praveen was Codema, which people don't need to know is run by FSCI; other examples include YouTube which I was surprised to learn many people don't even realise is run by Google, even though it has the same login etc.).

Specifically, I think Akkoma and Pixelfed would work best if they were directly on durare.org without any subdomain. Unfortunately they're both flagship services so we'll have to choose one. Some ideas:

• Perhaps some Android users can check if the Pixelfed app works on Akkoma so we can get away hosting just one of them?

• I haven't investigated frontends, but there might be one that allows multiple logins so we can automatically link both Pixelfed and Akkoma to that one. Even if the AP handles are different, people can at least access them using the same domain (i.e. the place hosting the frontend).

In the longer run, I think when we have services where each community gets their own instance (and therefore ideally on their own subdomain) then having a separate domain for those is better to avoid multi-level subdomains. Examples include Ghost, Ibis, and maybe even NextCloud.

That said I think subdomains would work for most cases. We can go into special cases later, after we've established that everyone here is, in principle, okay with durare.org or its subdomains being used for whichever of these services we decide would benefit from it.

@Kushagra J may be make a poll for sub domain vs tld in general or may be this can be decided per service later too.

While we initially wanted to use durare.org subdomains for consistency, we wondered if we could have a name that was more immediately meaningful for Indians, since this is a service primarily aimed at Indian users.

We had the following criteria in mind -

1. It has to be easily communicated, verbally, to most Indians. It cannot be an uncommon word, or phonetically similar to another word.

2. It's a service for Indians, so a word from an Indian language is preferable.

3. It has to sound appealing to most Indians. (So nothing polarizing or scandalous.)

4. It should reflect our values (decentralization, freedom, privacy, etc)

5. The domain has to be cheap(ish).

We discussed names for many days, before settling on "megham" (which means "cloud" in many Indian languages). As for TLDs, we had the following available -

1. megham.space

2. megham.cloud

3. megham.quest

4. megham.club

5. megham.my

6. megham.xyz

7. megham.one

8. megham.studio

9. megham.social

10. megham.online

Among them, the following seem to be the favorites among us -

1. megham.space

2. megham.cloud (yes, it's a little redundant, but in a fun kind of way)

3. megham.quest (because we are on a quest, a mission to decentralize our communication)

4. megham.club

5. megham.my

Was wondering if the base name sounds okay to the Durare community (or if there are other suggestions), and if so, which TLDs they prefer.

Among the above-mentioned, megham.cloud sounds the best to me.

Since there haven't been any objections, we'll proceed with one of the shortlisted names.

@fugata I would argue that "online" has a connection because our aim is to provide various online services

@Ravi Dwivedi you could have rigged the votes by putting less popular ones high and more popular ones low

@Pirate Praveen Added.

Has anyone checked on the costs of renting these domains?

@fugata Has the domain been bought?