5 ms·

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 ins

by mg 3y ago

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.

cmckn 3y ago
How is running a web server for a JSON file easier than creating a TXT record in your DNS?
- mg 3y ago
  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"
  - aaomidi 3y ago
    But why
  - blitzar 3y ago
    > 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).
- cmckn 3y ago
  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>"}
bnewbold 3y ago
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.
- mg 3y ago
  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?
  - bnewbold 3y ago
    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.
    - mg 3y ago
      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?
tedunangst 3y ago
Activitypub identities are URLs, nothing more. https://social.example.com/pickleman 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.
- mg 3y ago
  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.
  - tedunangst 3y ago
    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.
    - mg 3y ago
      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?
      - sieabahlpark 3y ago
        [dead]
      - tedunangst 3y ago
        It's https://masto.ai/users/mg 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 https://www.w3.org/TR/activitypub/#obj-id
deleted 3y ago
[deleted]
amadeuspagel 3y ago
If you have your domain pointed to a substack, you can still edit the DNS records, but you can't upload JSON files.

by mg 3y ago

cmckn 3y ago

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

mg 3y ago
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"
- aaomidi 3y ago
  But why
- blitzar 3y ago
  > 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).
cmckn 3y ago
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>"}

bnewbold 3y ago

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.

mg 3y ago
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?
- bnewbold 3y ago
  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.
  - mg 3y ago
    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?

tedunangst 3y ago

Activitypub identities are URLs, nothing more. https://social.example.com/pickleman 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.

mg 3y ago
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.
- tedunangst 3y ago
  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.
  - mg 3y ago
    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?
    - sieabahlpark 3y ago
      [dead]
    - tedunangst 3y ago
      It's https://masto.ai/users/mg 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 https://www.w3.org/TR/activitypub/#obj-id

deleted 3y ago

[deleted]

amadeuspagel 3y ago

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