This extension allows users of your site to set their bluesky domain to <slug>.<yourdomain> replacing the commonplace bsky.social domains all users are assigned by default.

Installation

Install with composer:

composer require webbinaro/flarum-bluesky-handles:"*"

Updating

composer update webbinaro/flarum-bluesky-handles:"*"
php flarum migrate
php flarum cache:clear

Screenshots

User settings to provide their DID

Updating domain/handle in Bluesky

Requirements and Configuration

  1. This extension uses fof/masquerade to define the new User Profile field.
  2. You DNS settings will need to send wildcard domain to your webserver
  3. Your webserver will need to route wildcard domains to the newly exposed endpoint /api/bluesku/<slug>
  4. Your SSL cert will need to be updated to support wildcards.

Example Nginx config is included in GH repo

    eddiewebb excellent initiative !

    Wouldn't it make more sense to return a 404 error in the wildcard config and only redirect the .well-known path? Or redirect to the Flarum user profile page when trying to open the subdomain in a web browser.

    I was a bit intrigued while reading the Bluesky documentation myself, they didn't put any suggestion on what to do with the subdomains homepage. I feel like it could have adverse SEO effect if it returns a 200 status.

    I don't understand why they didn't create a system that didn't rely on multiple subdomains. They could have specified a special DNS record that refines a single authoritative REST API endpoint, or allow the apex domain to list multiple key-values in a single .well-known endpoint. I feel like it would have been a lot more practical.

        clarkwinkelmann For our use case as flarum extension I think the idea of redirecting subdomain requests without matching .well-known path to user profile is a good one.

        For the broader bluesky setup thought it is important to keep in mind that the handle IS a domain, and intended to be acquired only by the legitimate domain owner. As such the owner needs to provide proof of legitimate ownership of the full domain. Most domains would have content on the root domain, i.e. a newspaper or company website, hence them not having opinions on how to handle content there.

        To allow a single apex domain endpoint to serve multiple handles could undermine that trust, as subdomains are sometimes controlled by individuals who don't control/have access to the root domain and vice versa. I think their approach to require access to the fully qualified domain name is very much in line with other domain related verifications I have encountered (either make a TXT record on the FQDN, or expose a file on the FQDN).

          I have updated the example Nginx configuration as suggested to only send full specified at-proto requests to my new API, all others go to user profile.

          • <user-slug>.example.com --> example.com/u/<user-slug>
          • <user-slug>.example.com/.well-known/atproto-did --> example.com/api/bluesky/<user-slug>

          This example also passes on any provide path, which means users can use subdomain as a vanity URL to do things like

          • <user-slug>.example.com/. (posts by default)
          • <user-slug>.example.com/discussions
          • <user-slug>.example.com/likes
          • <user-slug>.example.com/masquerade
          server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    # listen for any subdomains EXCEPT known ones...
    server_name ~^(?<slug>(?!other-suddomain-to-exclude)\w+)\.example\.com$;

    if ( $request_uri ~ ^/.well-known/atproto-did ) {
        # send atproto did verification requests to custom endpoint
        return $scheme://example.com/api/bluesky/$slug;
    }
    # send all other requests to subpath of user profile
    return $scheme://example.com/u/$slug$request_uri;
...
}

          I started going down the path of adding a custom controller for the .well-known/atproto url but this seemed more simply handled at webserver layer.