@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.

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?

@fugata like I mentioned in the xmpp group, many people may not be using multiple services so sub domain becomes a bit inconvenient if they use only one service primarily. They have to remember the subdomain extra. Some services might allow sharing the main domain through dns entries. For example prav xmpp service is hosted under regina.prav.app but accounts are @prav.app since we have setup SRV records that xmpp clients can understand. Same way poddery.com is shared between matrix and xmpp without using a sub domain in the address. I would also caution you against starting many services even in a single phase. Consider expanding one by one. This will reduce the crowd funding target for each phase and you will have less pressure to setup / maintain. Also consider the reliability factor, muppeth dedicates many hours for disroot. How are you going to respond to emergency situations like disk is full, server goes out of memory or the service gets killed randomly due to bugs etc ? (all of this happens to services I maintain at work). The more services you offer chances of issues also increases. Another factor is payment for hosting, poddery goes down almost every month since bill is not paid in advance and the card can't pay automatically. So you will need an international credit card or pay in advance etc. I am just sharing possible issues based on experience, if you plan ahead, you can reduce pressure. If you plan and pay the bills before the server is down, you can avoid the down time and don't have to be under pressure to bring it back. But more people will need to take responsibility and be proactive. Somehow we failed in that for poddery.com as almost every time we pay after the server is down, even when we clearly know paying it ahead can avoid that down time, no one has stepped up to do that. Luckily for Prav, we have Sajith who paid in advance (still it went down once the balance was zero and we did not notice).

fsci peertube instance (https://videos.fsci.in) don't have any maintainers. I suggest you consider maintaining it instead of a new instance. You could have multiple alias domains too for same instance. You might also want to consider using a single sign on system based on ldap or oauth or openid connect.

Like how many services use email address as username, one account can still be used even if domains are different. gmail.com and drive.google.com as examples. It does not have to be sub domains to share a single account.

@Pirate Praveen Re: hosting costs and responding to emergencies, I'm thinking of crowdfunding all costs for phase 1 first (for say 1 year) -

1. hardware

2. domain (if needed)

3. dev/admin payment, by approximating person-hours (e.g. 30 person-hours a month)

Thus, we'll hopefully have all costs paid in advance. The dev/admin payment will be distributed based on the time invested by people in dev/admin tasks. Of course, this is tricky to get right (it depends on people reporting their hours accurately), but it's the best way I've been able to figure out given the number of people involved...alternative ideas welcome!

I'm totally in favor of maintaining existing services like videos.fsci.in.

Re: domain, I understand that we don't need subdomains to share a single account, but I still prefer subdomains to have a "unified identity" of sorts. Maybe we should have a poll for it... 🤔

@Pirate Praveen Re: emergencies
We are also hoping to get more volunteers and moderators as we scale (which hopefully shouldn't be very hard). But I agree with @Pirate Praveen, we should scale one service at a time, instead of attempting to run multiple services at once.

Re: domain
I agree with @fugata, about the unified identity aspect. Our goal is to run multiple services under a single name, kind of like disroot.

Possibilities,
1. Use different domains for every service
- more accessible and memorable
- higher costs
2. Use subdomains
- unified identity
- less memorable

also I don't think we've cleared up if you'd be open to have this as a part of the durare project (not necessarily with it's name and domain).

@Kushagra J I personally don't have a problem in reusing the domain if you manage to raise the funds upfront (and you already seems to have many volunteers). May be make an explicit poll if you actually like to use durare.org sub domains.

at least for poddery.com and diasp.in (and other fsci managed services) getting new volunteers have not been easy. So usually it ends up as having one or two people who care have to jump in and fix things always or things keep broken for a long time (like poddery.com homepage or the xmpp service - both were broken for long periods of time since no one stepped in even after repeated calls for help). So I'd recommend you talk about new volunteers based on experience. Creating/starting a new service is more exciting to many people than keep on maintaining it (which starts to get boring after a while - one way out would to be to pay for the time spent).

For poddery.com, we did try to raise money to pay admins - but we did not succeed, we got barely enough to pay for hosting. Now poddery.com hosting costs are paid by @Kannan V M alone, he keeps asking for others to contribute every month. But I don't see anyone stepping in or helping to run a crowd funding campaign. Basically my experience so far with volunteer run services has not be very happy one so I keep telling new people to be careful before jumping in. Prav is better in that regard, we managed to get money for hosting that covers for at least a year - though from a single person. But there is a clearly defined process to get money and we have been getting money enough to run the service so far.

@Pirate Praveen All would depend on how successful our crowdfunding/grant attempts are. We are trying to minimize costs as much as possible by using durare subdomains and hoping to run services on private physical hardware (which comes with it's own set of problems). As you've pointed out earlier, it's sensible to start out with a single service and see if we're able to sustain that.

Since we're mostly aiming to run fediverse services, starting out with Akkoma/Mastodon should be fair.

(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).

@Pirate Praveen that works when people find durare first. However, in scenarios where they come across the hosted service first, they would not find out about durare as easily compared to when durare is part of the domain.

(Nit: Gmail is hosted as a Google subdomain - mail.google.com. YouTube didn't start out as a Google service and was an acquisition which would explain the separate domain.)

@Ceda EI mail addresses are still @gmail.com and most people would be visiting gmail.com and not mail.google.com Each service can also highlight it is part of the Durare project. But anyway we can decide on a case by case basis for each services as most people agreed to. We can also have aliases were possible (like social.durare.org and durare.social).

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.

@Pirate Praveen think we can decide that later. We just wanted to know if durare would allow us to use their subdomains at all.

@Kushagra J agreed

Don't mind that discussion starting now though 🙂