Serve federated apps from root domain

[yusf]

I've written about this issue in various topics where related but now want to distill those thoughts in a dedicated one.

Federated services?

Various services that are federated in one way or another typically serve from the root domain. A few examples:

• Matrix, a popular federated chat service. (1 587 public servers with ∞ users)
• Mastodon, a very popular federated microblog service. (2 744 public servers with 2 270 595 users)
• PeerTube, a somewhat popular federated video streaming service with peer-to-peer content distribution. (340 public servers with 23 164 users)
• PixelFed, an emerging federated Instagram-like image service. (107 public servers with 15 966 users)
• WriteFreely, an emerging federated blogging platform. (199 public servers with 5 490 users)
• IRC, a well established chat service. (∞ public servers with ∞ users)
• Email (∞ servers with ∞ users)

Problem

Regardless of what subdomain these services are served from technically, they all require some routing via the root domain to work properly. Sure, some can be served from a subdomain but it's bad practice.

In Cloudron, support for this type of routing is currently absent except for email (which is obviously because it makes up such a central component of the Cloudron system). The routing required for federated services typically means forwarding a port or two towards the true location of the service.

Proposal

The solution I imagine is that apps requiring this routing registers extra ports in their app manifests that then targets the root domain, which should still be open to serve a completely different app on that location as well. Just like email works right now alongside whatever is installed on the root domain.

Now, if Cloudron were to accomodate for this type of root domain routing then the system would be quite ideal for hosting not only the typical web apps already possible, but the whole plethora of emerging federated services as well. The numbers shows a pretty good interest in these types of services.

Let's hear it

I'd hereby like to initiate a solution oriented discussion on this topic. I would especially appreciate the views of @girish and @nebulon, but of course community members like @msbt, @murgero, @kasini and @october as well.

[will]

I really think decentralized and federated services are EXACTLY the same market that self hosts at the non-business level. Cloudron would be ahead of the curve here. I STRONGLY suggest a in depth look into federated services for the Cloudron platform.

A cool list to check out:
https://github.com/gdamdam/awesome-decentralized-web

[murgero]

I see a lot of mastodon, pixelfed, pleroma, etc etc services running on, and registered using social.domain.tld - Seems to be the norm except for the few that are branded.

[yusf]

@murgero That could be because they don’t know how to set it up correctly either. You can set up email addresses the same way if you really want to but it just as weird.

But there may be different practices around each project depending on if the web app its decoupled from the server or not. At least in Matrix server best practice it’s not come on at all.

[murgero]

@yusf Normally you would have different services on different FQDNs per RFC:

www.domain.tld = Web server
social.domain.tld = Social media
voip.domain.tld = VoIP services
xmpp.domain.tld = XMPP

So on and so forth, then using DNS you can do stuff like (using XMPP as an example):
SRV RECORD _xmpp-client._tcp.domain.tld 0 10 xmpp.domain.tld

Then allow users to use username@domain.tld (but services still on xmpp.domain.tld)

Mail works the same way because you setup autoconf.domain.tld (or whatever the DNS record is I forget) that tells most email clients where to go for mail for a particular domain (as opposed to MX records which is primarily for servers.)

[yusf]

@murgero I’ve seen this too but it seems like the next generation services, like Matrix, requires proper reverse proxying instead of SRV records.

[murgero]

@yusf Matrix is a bad example, as it does support DNS SRV records:
https://github.com/matrix-org/synapse/blob/master/docs/federate.md

It also supports using the .well-known folder trick (see link above). but I am in agreement with your OP. I am just making sure all options are on the table. Services like Matrix, XMPP, Mastodon, etc support DNS SRV records for the "redirection" you speak of.

So having an option for the Manifest file to specify SRV, TXT, etc DNS records would be very nice to have, especially for Nextcloud (it supports federation and ActivityPub!), Matrix, etc.

[yusf]

@murgero To my knowledge that part of the Matrix documentation is outdated and use of SRV deprecated in favor of the .well-known solution, but I might remember it wrong. SRV records certainly wasn’t enough for me setting the thing up.

Here’s a similar discussion regarding Mastodon and SRV records with the author of Mastodon:

The browser can't act on SRV records so what use would they be?

This seems to be the problem with SRV nowadays, that web apps don’t understand them.

[murgero]

@yusf Ah Gargron and I don't get along these days lol We had a falling out after I wrote some installation documentation for him back in the early days of Masto.

That said, .well-known might be a better option for Web-based apps. (Not to say web apps couldn't use SRV records, cause they could with some simple JS for DNS lookups.)

[fbartels]

I think in the end this pretty much depends on the individual application as not all are following the same mechanisms for distribution. All dns based lookups you could already configure yourself, although it surely makes it easier of Cloudron can set these entries up as well, for http based lookups a generic "forward this url from app x to app y" sounds like a simple task.

[yusf]

@fbartels said in Serve federated apps from root domain:

for http based lookups a generic "forward this url from app x to app y" sounds like a simple task.

Yes, this is currently the biggest blocker.

[girish]

@yusf Thanks for creating this! I am fairly new to these apps and concepts of fediverse itself, so please bear with me

I am trying to understand what sort of routing is needed in the root domain for these apps to work. So far, I have only looked into matrix and mastodon.

1. For matrix, you can set server_name and use SRV records to locate the actual matrix server. Federation uses port 8448 (this can be added to Cloudron package). In addition, we can configure reverse proxy for the federation port so that matrix doesn't need TLS certs (which we like for security reasons).

2. mastodon has moved to ActivityPub (PR). From light reading, it seems so has peertube and pixelfed. All these used to use webfinger but have since moved to .well-known/host-meta. The idea is if you have an account acct:girish@cloudron.io, it will first look up https://cloudron.io/.well-known/host-meta which will return a LRDD link which is a template URI like https://social.cloudron.io/.well-known/webfinger?resource={uri} (this is 'webfinger' only because mastodon already supports webfinger). Then we make another query https://social.cloudron.io/.well-known/webfinger?resource=acct:girish@cloudron.io which returns a JSON containing a subscribe URL as well as a the ActivityPub stream. mastodon has decided not to support SRV records. It seems the reason is that ActivityPub is entirely HTTP based.

So OK, maybe Cloudron can have a setting to respond with host-meta. But afaict there is actually no way to map a single account (acct:girish@cloudron.io) to multiple apps. That is, I cannot use peertube, mastodon, pixelfed with the same account (acct:girish@cloudron.io) at the same time. This comment seems to agree with that since we can only direct the webfinger to one of the apps. Can someone confirm this is the case?

(If that is the case, I would argue that the correct approach to federation right now given the state of the apps is to just have account names to be the same as the domain in which the apps are installed - like girish@mastodon.cloudron.io, girish@peertube.cloudron.io and so on. And for such setups, we don't need anything extra in Cloudron).

[yusf]

I’ll read up on your reply more thoroughly later but regarding Matrix and SRV records, Matrix’ newer .well-known approach has precedence over the SRV approach, which is itself still in place to serve legacy server versions (pre 1.0). So I’d argue that this approach is of deprecated status.

https://github.com/matrix-org/synapse/blob/master/docs/MSC1711_certificates_FAQ.md

[girish]

I found the matrx spec for resolving server names - https://matrix.org/docs/spec/server_server/r0.1.2#resolving-server-names .

I will assume that the normal setup is people install synapse at matrix.example.com but want server_name as example.com. For this, if we setup just the SRV records at example.com (step 4), then matrix.example.com needs the certs of example.com per the spec. IMO, this would be very complicated for the user to provide and setup. The best fix is to provide .well-known records at example.com to delegate to matrix.example.com. In this case, matrix.example.com does not require the certs if we setup a reverse proxy in the front (easy with nginx).

So, how to support matrix is clear to me. How to support ActivityPub is not.

[girish]

OK, I did another round of searching for answers.. I understood a lot from these two posts - https://schub.wtf/blog/2018/02/01/activitypub-one-protocol-to-rule-them-all.html and https://schub.wtf/blog/2019/01/13/activitypub-final-thoughts-one-year-later.html (from one person behind diaspora).

It seems the apps started out initially just federating with instances of themselves. When this was the case, they used webfinger for discovering accounts and information about an account. All the apps are just using @username@installation_domain (and not root domain). Peertube has no setting like LOCAL_DOMAIN - https://github.com/Chocobozzz/PeerTube/blob/develop/config/production.yaml.example#L6 . Same for pixel fed - https://github.com/pixelfed/pixelfed/blob/dev/.env.example#L7 . I guess nobody has gotten to the point of having the same @username@rootdomain to be used across apps. This makes sense because the apps don't really talk to each other apart from providing an activitypub stream. Think of it as each of those document editors supporting MSXML. None of them could load each others stuff in the very early days.

In essence, the correct approach for Cloudron for now is to not let LOCAL_DOMAIN be configurable in mastodon. It's just confusing that it even exists without the surrounding standards to support it across apps.