Hacker News Reader

Comment by mg | Hacker News Reader

What the AT protocol got right is that your handle is also a url. Because it is a hostname.

I always thought ActivityPub should have used hostname/username instead of @username@hostname for the handle. Then they would have that advantage too. And one less char in the handle.

What I find a bit cumbersome with the AT protocol is that it uses DNS records to store the metadata of an identity. I wonder if it should have used a simple json file instead. So that the protocol would not look at the DNS records of a hostname for the metadata but at hostname/at_identity.json

That woule make it much easier for owners of a hostname to use it as their AT identity. Building tooling around the AT protocol would also get easier.

View on HN

How is running a web server for a JSON file easier than creating a TXT record in your DNS?

Then when you want to use the AT protocol without a webserver, you would have to set a DNS entry (CNAME) that points to a service like Bluesky. So for users without a web server, it would stay the same amount of work.

And for others it would be just

echo 'my metadata' | ssh myhost "cat > /my/web/dir/at_identity.json"

But why

> And for others it would be just

+ hosting the server + admin the server + securing the server + keeping the server up all the time

For trivially small amounts of data it seems a massive waste of time and effort.

If however, you are storing and verifying identity of 100's+++ of users within said domain then hosting that makes sense (pgp for email should probably work this way).

Nevertheless, they’ve added this a couple days ago. Someone has already created an S3 bucket called “xrpc” and is using s3.amazonaws.com as their handle. :)

—— From @emily.bsky.team:

you can also use a non-DNS option — serve some JSON at a well-known endpoint (similar to webfinger)

  GET https://<users-handle>/xrpc/com.atproto.identity.resolveHandle
  {"did":"<users-did>"}

atproto handle resolution tries DNS TXT first, then will try an HTTP endpoint. the endpoint is not a ".well-known", it is an "/xrpc/"-prefixed endpoint with a query parameter, which is workable on some static hosts (like github pages), but not others.

not well documented yet. may try to do a ".well-known", but don't want a sprawling set of options with complex priority levels and caching behaviors.

Nice! So the file approach does work. Do you have a link to the documentation of the file approach?

Why does the DNS approach exist at all? Couldn't users who own a hostname but have not connected it to a webserver have achieved the same by adding a CNAME to a service like Bluesky?

I don't really understand your question.

Maybe it helps to clarify that the concept of a handle is totally distinct from the "Personal Data Server" or PDS. You look up the PDS for a handle by resolving the DID first (via DNS TXT or HTTP fallback), then get a DID document, which has a URL to the PDS. This is a bit confusing and multiple steps, but is what makes the handles so easy to use. It is totally fine to have a cool domain to use as a handle and just not have a webserver associated with it.

If you pointed the domain with a CNAME to a particular service, you would need to update that every time you change hosting providers. Which is maybe not often, but it would be disruptive and potentially poor experience because of DNS propagation issues.

For a hypothetical brand like google.com, look up the TXT records. There are a bunch of verifications for various services. This is a relatively standard mechanism. TTL and caching are built-in to DNS, or you can punch through with a recursive query when needed.

The challenges around changing hosting providers are the same for websites, aren't they? It seems to me they are well understood these days. I don't hear many people having a pain point around it anymore. A short TTL usually is enough to avoid a lot of DNS caching issues.

And wouldn't changing the name server have the same effect on the DNS solution? "Every time you change your name server provider ...". Which for many users is the same as their hosting provider.

Do I assume correctly, that you don't link to the HTTP fallback documentation because you don't want people to use it?

At this point not just using webfinger just feels contrarian for the sake of it.

But then again so does a whole lot of Bluesky. That is, a whole lot of Bluesky could have been designed to interoperate with the fediverse without sacrificing functionality. The choice to instead privately design something entirely different to me speaks strongly to an attitude to openness and community building that makes it a non-starter for me.

I kind of like that they're tying it to DNS, which is probably the most successful decentralized system to date.

Fediverse doesn't really seem to scale at the individual server level, which is a sort of weird UX.

Creating a domain name is both cheaper and easier than running your own fediverse server.

Webfinger is entirely separate from ActivityPub, and is already used by other things like e.g. RemoteStorage.

Even if we postulate that what you say is true (I don't agree it doesn't scale, and there are increasingly commercial offerings if you don't want to run your own and there will be more, but let's put that aside), none of that stops people from using webfinger. If you want more than one user on the domain, it requires at a minimum the ability to dynamically rewrite a URL to redirect to a static URL (or you can of course have a fully dynamic endpoint), otherwise it just requires the ability to serve up a single static file.

While I kind of like using DNS myself, and might have gone that way if starting from scratch without an alternative existing, the existence of webfinger and the fact it is in use for multiple things would have made me stop and think twice and just use webfinger.

To late to edit here, but an additional thought: If Bluesky starts getting traction, a move to undercut it from Fediverse proponents would be embrace and extend: Augment clients with webfinger, provide bridging to the Fediverse, and generally aim to make Bluesky users expect to be a part of the wider Fediverse. Only if Bluesky very rapidly overtakes Mastodon to the point of dwarfing it or remain an irrlevance, will it have a realistic prospect of remaining what they want it to be rather than turn into some hybrid that runs away from them.

Webfinger needs to be updated or replaced anyhow - it wasn’t specified in a static file hosting compatible way and expects a dynamic response or custom server rules. Not that bluesky helps here either.

It's easy to do. Here are some examples: https://www.packetizer.com/ws/webfinger/server.html

I actually serve up content using both static files and via dynamically generated content, depending on the domain and needs.

Those are steps for running a server with rules engine. I don’t want a server, I want users to be able to access a CDN directly which may not have such flexible rewrite rules. I’m building a kind of bluesky alt that works entirely statically and should be flexible to file hosting

Activitypub identities are URLs, nothing more. https://social.example.com/pickleman is an activitypub identity.

Some people layered webfinger mentions on top of that, but the protocol neither uses nor depends on it.

Unfortunately not. Activitypub Identities are @username@hostname.

When you have one of these and want to find the user, you have to ask hostname at ...

    https://{hostname}/.well-known/webfinger?resource={...}

... for more infos about the user. {...} being an urlencoded version of "acct:{user}@{hostname}".

Then you will get a bunch of stuff, including so called "aliases". Which are urls. Many services provide aliases of the form hostname/@username or hostname/users/username. Which are endpoints that display something about the user. But that is not part of the protocol and differs from service to service.

Totally backwards. The AP identity is whatever url endpoint you want it to be. People use webfinger to turn @handles into that url, but you can also just use the url directly. Grab the actor, find the inbox, send your post.

That is not how I read the specs. Let's look at an example:

My handle is @mg@masto.ai

What is my "AP identity" in your interpretation of the AP protocol?

It's https://masto.ai/users/mg. You can see it by running curl -H "Accept: application/ld+json".

https://www.w3.org/TR/activitypub/#obj-id

That is one of the aliases. The same holds true for ...

    https://masto.ai/users/mg
    https://masto.ai/@mg

... and the server could povide as many aliases as it wants to.

I wouldn't call those "identities". As the server could just change the aliases and the handle "@mg@masto.ai" would still work. Because it resolves to whatever aliases the server provides via the webfinger endpoint.

I have not seen anything in the specs that says the aliases are identities or should stay the same over time.

Try this:

    curl -H "Accept: application/json" https://masto.ai/users/mg/following?page=1 | jq .

Notice the people you are following are referenced by URL. If you try /followers instead, and look up the following URLs of some of your followers, you'll find that they follow you by the URL

    https://masto.ai/users/mg

If you do:

    curl -H "Accept: application/json" https://masto.ai/@mg | jq .id

You'll see that the returned document shows the id of your ActivityPub Person actor as https://masto.ai/users/mg, not https://masto.ai/@mg or @mg@masto.ai.

@mg@masto.ai can change and nothing will happen (even old mentions should still work, as at least Mastodon resolves the mentions to the Actor url and includes a mapping in the post). But if the https://masto.ai/users/mg URL changes, you will need to trigger a move, or you'll lose your followers, because from their servers point of view, that URL is your identity or in ActivityPub speak it's the identity of your Person Actor and for most purposes that's all ActivityPub cares about.

So while you can introduce aliases in webfinger, and for the purposes of webinger your id is mg@masto.ai, if the primary ID of the ActivityPub Person actor changes, you need a "movedTo" element to point to the new one, an "alsoKnownAs" to point to the old one, and trigger notifications to the servers of your followers and following for things not to break horribly. See e.g.:

    curl -H "Accept: application/json" https://mastodon.social/@vidarh | jq .movedTo

And

    curl -H "Accept: application/json" https://m.galaxybound.com/users/vidar | jq .alsoKnownAs

This is not in the ActivityPub spec - it was added as an extension as people started to want to be able to move more smoothly.

(I personally don't like this dependency on the old server in the move process, and so one of the few things I actually like about BlueSky is the ability for a user to take their data to a new server unilaterally; that could be fixed for the Fediverse without an entirely new protocol, however - it just needs a mechanism similar to the recovery key mechanism of BlueSky to let users prove who they are on a new server)

In effect, you have two identities in the Fediverse:

* You have a webfinger identity acct:mg@masto.ai

* You have an ActivityPub Person actor identity https://masto.ai/users/mg

Changing the former, or adding more of them (you can even just add a redirect on your own domain and user@yourowndomain will work and resolve to your https://masto.ai/users/mg identity; this is how my Mastodon is on m.galaxybound.com but my preferred Mastodon handle is @vidar@galaxybound.com without the "m."), is easy. Changing the latter is complex (more than it should be).

    curl -H "Accept: application/json" https://masto.ai/users/mg/following?page=1 | jq .
    Notice the people you are following are referenced by URL.

That we can see entries of the form hostname/users/username in the output of a that specific curl command is proof that it is the identity of a user as defined by the ActivityPub protocol?

Shouldn't we be able to look at the ActivityPub specs and see how the identity of a users is defined?

To quote the spec:

    'In ActivityPub, a user is represented by "actors" via the user's accounts on servers.'

and:

    'All Objects in [ActivityStreams] should have unique global identifiers. ActivityPub extends this requirement; all objects distributed by the ActivityPub protocol MUST have unique global identifiers, unless they are intentionally transient (short lived activities that are not intended to be able to be looked up, such as some kinds of chat messages or game notifications). These identifiers must fall into one of the following groups:

    1. Publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server. (Publicly facing content SHOULD use HTTPS URIs).

    2. An ID explicitly specified as the JSON null object, which implies an anonymous object (a part of its parent context)'

and:

    'All objects have the following properties:

    id
    The object's unique global identifier (unless the object is transient, in which case the id MAY be omitted).'

So a user is represented by an Actor, an Actor must have a global identifier, and that global identifier is the "id" field in the JSON. https://masto.ai/users/mg in your case.

(You may also search the ActivityPub spec for "webfinger"; it is not mentioned - it's a convenience offered by implementations like Mastodon, and not required by the ActivityPub spec at all; your interop with Mastodon will be harmed if you don't support it, but it'll work - users just need to input your url instead)

EDIT: to further underline the relationship of Webfinger to ActivityPub, look at the section for Actor's [1], and how the use of webfinger lookups violate the spec ("otherwise, the entered value should be considered invalid") - it's an extension/change used by things like Mastodon for user convenience, and not part of ActivityPub itself at all.

[1] https://w3c.github.io/activitypub/#actors

Awesome!

That's pretty cool. So the ID of an ActivityPub actor is simply a url.

That is great.

I think Mastodon should have made it so that the url for their users is hostname/username and that is their ID as well. That would have prevented a ton of confusion.

I think there'd have been confusion either way, with people expecting to put the URLs into a browser rather than a social app, especially as there's no uniform way of recognising that they're Fediverse-related without visiting the URL first, so I think having an indicator of that there is worth it, but e.g. the masto.ai/@mg style URL are a lot better than the masto.ai/users/mg.

The webfinger support also potentially enables some cool functionality by letting users use the same handle for multiple services. That said, I'd love to see someone set up a webfinger service that 1) lets people bring their own custom domains, 2) shows a linktree style UI if you hit host/username, 3) optionally redirects or transparently caches certain settings, 4) offer to transparently redirect requests to the user page a given resource based on Accept: header where possible (e.g. ActivityPub/ActivityStreams technically expect 'application/ld+json; profile="https://www.w3.org/ns/activitystreams" ' with the caveat that the "profile" bit is likely to be left out by a lot of clients)

You're thinking of Mastodon. There's no mention of using @ in identities at all in the ActivityPub spec: https://www.w3.org/TR/activitypub/#actor-objects

Usernames can be represented as whatever, but they're not the user IDs.

Peertube implements ActivityPub and uses username@server instead of @username@server, and so does Pixelfed. Funkwhale uses https://hostname.tld/federation/actors/Alice as their ActivityPub identifier (they support multiple federation protocols) and doesn't have a clear representation of user + domain as far as I can tell.

There is no mention of "identities" or "identity" in the spec either.

So if a person is available via ActivityPub, how do they reference their "identity"? When you want to say "Follow me via ActivityPub: ..." - what is "..."? The most common form I see is @username@hostname. Is there a more universal form? How does a Pixelfed user do it?

The most common form is @username@hostname, sure, because it's convenient, and also because doing a webfinger lookup of that is more generic - a webfinger response can include far more than AcrivityPub endpoints.

But specifically for ActivityPub the URL works just fine (try pasting it in the Mastodon search box, for example, and up pops the user details exactly as if you'd used @user@host)

You say "the url works" as if there is a clearly defined url for every Fediverse user. But the way I read the specs, that is not the case.

Some servers link you to hostname/users/username, some use hostname/@username, some use hostname/username when you look up a user via webfinger.

And the way I read the specs, those don't have to be permanent. A server could change their scheme from hostname/users/username to hostname/u/username and would not violate the protocol. Because the way to identify the user is via a webfinger lookup.

Maybe the only way to say who you are on the Fediverse is "I am <username> on <hostname>. Look me up through Webfinger"?

That might be the equivalent of saying "I am https://masto.ai/.well-known/webfinger?resource=acct%3Amg%40..."

> You say "the url works" as if there is a clearly defined url for every Fediverse user. But the way I read the specs, that is not the case.

There is a clearly defined URL for every Fediverse user, but not in the sense you mean (there isn't a static or predictable mapping from user@host to URL). The Fediverse is a graph of Person actor urls, not @user@host ids. The Webfinger lookup functionality is used because it makes things more flexible for users and because webfinger allows for a single identity to refer to multiple different types of services and resources, but my followers servers and the servers of those I'm following knows me as https://m.galaxybound.com/users/vidar even though @vidar@galaxybound.com is what I use.

> And the way I read the specs, those don't have to be permanent. A server could change their scheme from hostname/users/username to hostname/u/username and would not violate the protocol. Because the way to identify the user is via a webfinger lookup.

See my other comment. A user is identified via a webfinger lookup when trying to determine which Person Actor @mg@masto.ai refers to. But in almost every other context the only thing that is stored is the URI of the Person actor. If that changes without using the (not in ActivityPub; new) move functionality, you're effectively creating a new identity, and quite a few servers do not yet support the move functionality, so while you can change @mg@masto.ai at a whim and nothing will break, changing the URL is what you need to be careful about (too careful, as I've noted elsewhere; the better support for migrating your data is pretty much the only thing I like about Bluesky)

Since more people are trying to prove you wrong, I’d argue it can’t be too late for Mastodon to fix that username scheme used in the frontend app. And agreed that double @ is stupid.

Mastodon supports URI's in the UI, and resolves @user@host names to profile URI's when you post as it is, so the use of webfinger is almost entirely a presentation/convenience issue anyway. I also dislike the double "@", but I get the thinking that starting "@" has to some extent become a signifier that what follows is a social handle.

If you have your domain pointed to a substack, you can still edit the DNS records, but you can't upload JSON files.

Reply on news.ycombinator.com