Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. Discuss
  3. Serve federated apps from root domain

Serve federated apps from root domain

Scheduled Pinned Locked Moved Discuss
federated
15 Posts 5 Posters 3.2k Views 8 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • murgeroM 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.

    yusfY Offline
    yusfY Offline
    yusf
    wrote on last edited by yusf
    #4

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

    murgeroM 1 Reply Last reply
    0
    • yusfY 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.

      murgeroM Offline
      murgeroM Offline
      murgero
      App Dev
      wrote on last edited by murgero
      #5

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

      --
      https://urgero.org
      ~ Professional Nerd. Freelance Programmer. ~

      yusfY 1 Reply Last reply
      0
      • murgeroM 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.)

        yusfY Offline
        yusfY Offline
        yusf
        wrote on last edited by
        #6

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

        murgeroM 1 Reply Last reply
        0
        • yusfY 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.

          murgeroM Offline
          murgeroM Offline
          murgero
          App Dev
          wrote on last edited by murgero
          #7

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

          --
          https://urgero.org
          ~ Professional Nerd. Freelance Programmer. ~

          yusfY 1 Reply Last reply
          0
          • murgeroM 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.

            yusfY Offline
            yusfY Offline
            yusf
            wrote on last edited by yusf
            #8

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

            murgeroM 1 Reply Last reply
            0
            • yusfY 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.

              murgeroM Offline
              murgeroM Offline
              murgero
              App Dev
              wrote on last edited by
              #9

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

              --
              https://urgero.org
              ~ Professional Nerd. Freelance Programmer. ~

              1 Reply Last reply
              0
              • fbartelsF Offline
                fbartelsF Offline
                fbartels
                App Dev
                wrote on last edited by
                #10

                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.

                yusfY 1 Reply Last reply
                3
                • fbartelsF 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.

                  yusfY Offline
                  yusfY Offline
                  yusf
                  wrote on last edited by
                  #11

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

                  1 Reply Last reply
                  0
                  • girishG Offline
                    girishG Offline
                    girish
                    Staff
                    wrote on last edited by girish
                    #12

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

                    1 Reply Last reply
                    1
                    • yusfY Offline
                      yusfY Offline
                      yusf
                      wrote on last edited by
                      #13

                      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

                      1 Reply Last reply
                      0
                      • girishG Offline
                        girishG Offline
                        girish
                        Staff
                        wrote on last edited by girish
                        #14

                        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.

                        1 Reply Last reply
                        0
                        • girishG Offline
                          girishG Offline
                          girish
                          Staff
                          wrote on last edited by girish
                          #15

                          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.

                          1 Reply Last reply
                          2
                          Reply
                          • Reply as topic
                          Log in to reply
                          • Oldest to Newest
                          • Newest to Oldest
                          • Most Votes


                          • Login

                          • Don't have an account? Register

                          • Login or register to search.
                          • First post
                            Last post
                          0
                          • Categories
                          • Recent
                          • Tags
                          • Popular
                          • Bookmarks
                          • Search