Key to trick was to have bucket named "xrpc" and store a file there: https://s3.amazonaws.com/xrpc/com.atproto.identity.resolveHa...
There is also another funny thing in the image, the user posting about is sending one from "retr0-id.translate.goog", which is odd. Somehow he has got https://retr0-id.translate.goog/xrpc/com.atproto.identity.re... to redirect to his page, and gotten that handle as well.
1. Bluesky allows you to use a domain as a handle by creating a TXT record on an _atproto subdomain of the domain you wish to use (see https://mxtoolbox.com/SuperTool.aspx?action=txt%3a_atproto.s... for mine)
2. You can also serve up your DID by having the URL "https://<handle>/xprc/com.atproto.identity.resolveHandle" return the DID.
3. AWS buckets have the URL structure http://s3.amazonaws.com/[bucket_name]/
4. register "xrpc" as an S3 bucket, drop a file named "com.atproto.identity.resolveHandle" with the correct JSON in it
5. boom! your username can now be s3.amazonaws.com
Hope that helps.
Webfinger is when you want to multiplex multiple identities on a single domain
E.g. https://example.com/.well-known/webfinger?resource=nick@exam...
Will serve the challenge proving your handle is @nick@example.com
A few things are effectively grandfathered in due to their vintage: /favicon.ico, /sitemap.xml and /robots.txt are the three that occur to me—so if you’re running something vaguely like S3, you’ll want to make sure users can’t create files at the top level of your domain matching at least those names.
But nothing new should use anything other than /.well-known/ for domain-scoped stuff, or else you run into exactly this problem.
I have my eyes on https://github.com/sugyan/atrium as a foundational library in this space, and expect folks to coalesce on it. But we'll see.
https://hachyderm.io/@jonty@chaos.social/110307532115312279
EDIT: Ah I guess if you're not logged into a hachyderm.io account, you get forwarded. So probably don't use the above link.
The issue with DNS-01 (and HTTP-01 to a lesser extent) as someone else mentioned is that the user friction is really high.
I’ve been working on a solution to this that I’ve been meaning to post to HN and this seems like as good an opportunity as any so here it is: [1]
It’s a method of storing a hashed (and optionally salted) verifiable identifier (think email or mobile) at a subdomain to prove authority for a domain.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/access...
(I don't know anything about this personally, but since a lot of people are indicating an interest in this detail of the story, figured I'd try and surface that link better!)
This is not how Mastodon does verification (at least not the main method). Mastodon doesn't just link users -> domain. It can link user -> webpage, for example to link social profiles between sites.
If you have a website with user generated content, and a user can set an arbitrary html attribute (rel="me") in a link pointing back to their profile, they can claim ownership of the page on Mastodon. Likewise, if they can set a link tag in the head element of the page for some reason.
Presumably this is somewhat harder to exploit than a (new, poorly thought out) dependency on a static file under /xrpc, but Mastodon does introduce more authentication footguns for sites than just .well-known! https://docs.joinmastodon.org/user/profile/#verification
Edit: authentication -> verification, since Mastodon distinguishes between the two (see below)
* The FediVerse is lots of WWW sites. Some are WWW-hosting companies showing off, with all of the acoutrements of high-end WWW sites, including CloudFlare protection and lots of tweaking of the back end stuff. Others are one-person sites where someone has just set up the vanilla Mastodon/Pleroma/Pixelfed/Friendica/whatever software on a cheap hosted VM somewhere. There are lots of in-betweens. I have an account on two sites, at each of the aforementioned extremes, one with well over 20,000 users and the other with around 40.
* It's really easy to deny service to the one-person sites, and many of the low-end ones.
* Chaos.Social's about page explains that it's a couple of people running a WWW site in their spare time on spare hardware. That's a little misleading, as they've upgraded the hardware a bit. But it's still 2 people, with ~5800 users. For more, start at https://meta.chaos.social/resources .
* There's nothing global in the FediVerse. Nothing gets sent everywhere. Some commenters here can see the post cached by their local WWW sites where they have accounts. But I'm in the opposite situation: None of the places where I have accounts have cached that post, and since the Chaos.Social sysop put the 429 error in place to combat the server overloading, they actually cannot pull that post with just its URL entered directly, although simple tricks like searching for @jonty@Chaos.Social instead and reading the user timeline work just fine.
* There's nothing global in the FediVerse. Using the aforementioned trick, I see a different view of the thread from Mastodon.Scot to what I see from Toot.Wales, and both of those are different to what's seen from other places.
You're thinking of how Mastodon does verified links. You could do something similar, provide a verified link on your profile to a file in an S3 bucket, but there's very utility (or risk) in that.
Mastodon also allows you to be discoverable via a custom domain, using .well-known as parent mentioned https://docs.joinmastodon.org/spec/webfinger/ https://www.hanselman.com/blog/use-your-own-user-domain-for-...
* ActivityPub -> AT Protocol (https://atproto.com/)
* Mastadon -> Bluesky (https://blueskyweb.xyz/)
Right now, federation is not turned on for the Bluesky instance.
There are differences in both, however. I'm not going to speak about my impressions of the Mastadon vs Bluesky teams because frankly, Mastadon never really caught on with me, so they're probably biased. ('they' being my impressions, that is, I just realized that may be ambiguous.)
At the protocol level, I haven't implemented ActivityPub in a decade, so I'm a bit behind developments there personally, but the mental model for AT Protocol is best analogized as git, honestly. Users have a PDS, a personal data server, that is identified by a domain, and signed. The location of the PDS does not have to match the domain, enabling you to do what you see here: a user with a domain as their handle, yet all the PDS data is stored on bluesky's servers. You can make a backup of your data at any time, and move your PDS somewhere else with ease (again, once federation is actually implemented, the path there is straightforward though). This is analogous to how you have a git repository locally, and on GitHub, and you point people at the GitHub, but say you decide you hate GitHub, and move to GitLab: you just upload your git repo there, and you're good. Same thing, except since identity is on your own domain, you don't even need to do a redirect, everything Just Works.
This analogy is also fruitful for understanding current limitations: "delete a post" is kind of like "git revert" currently: that is, it's a logical deletion, not an actual deletion. Enabling that ("git rebase") is currently underway. Private messaging does not yet exist.
Anyway if you want to know more the high-level aspects of the docs are very good. Like shockingly so. https://atproto.com/guides/overview They fall down a bit once you get into the details, but stuff is still changing and the team has 10,000 things to do, so it's understandable.
https://pagespeed.web.dev/analysis/https-twitter-com-realDon...
Mastodon.social is actually much faster on this particular benchmark. So maybe there is hope.
The hacker news DDOS is real.
Previously: https://news.ycombinator.com/item?id=34691489
https://mailarchive.ietf.org/arch/msg/apps-discuss/1_a06NU8z...
> 1) I feel that /host-meta is too casual of a name and prone to collisions. It matches /^[\w\-]+$/, which I think is a subset of a fair number of sites' usernames."
...
> i.e. put something ugly and weird in there, like a semicolon, to minimize the chance that it interferes with people's existing URL structure.
Fun bit of history!
Absolutely. I'm not saying that I think that the title here is good. Just that I understand why it ended up as the title.
> I don't know how this "discouragement" is phrased,
You can find the guidelines here: https://news.ycombinator.com/newsguidelines.html
To quote the relevant part:
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
That's it.
> (which I don't have a grasp of, even after following the cryptic link)
I described it over here, if you're still curious: https://news.ycombinator.com/item?id=35820670
It's not beyond the bounds of possibility. Compare https://github.com/mastodon/mastodon/issues/15431 .
https://wiki.archlinux.org/title/XDG_Base_Directory
I support both well-known and XDG because I think the benefit outweighs that perhaps they could have been designed better. But I don't think that those who opt out of it could only be doing so out of ignorance.
This person says they got 12k visitors over a day:
https://nicklafferty.com/blog/what-happens-when-you-re-on-th...
The websites hugged to death by this forum are usually tiny hobby projects.
https://mastodon.social/@jonty@chaos.social/1103075321453803...
> It builds off of several specifications that came from the crypto crowd. It does not use a proof of stake or proof of work blockchain, though, so depending on how you use the words "crypto" and "blockchain," it either is or is not those things.
From the protocol's FAQ docs itself:
> Is ATP a blockchain?
> No. ATP is a federated protocol. It's not a blockchain nor does it use a blockchain.
https://atproto.com/guides/faq#is-atp-a-blockchain
Architecturally, it's an attempt at improving ActivityPub in terms of account transfers & portability between federated instances, which ActivityPub doesn't inherently support. Mastodon, by comparison, requires one of those steps to be the explicit export into a locally-saved file, rather than communications between the federated instances themselves.
One of my blog posts was submitted to HN that had 194 points and 149 comments[1]. All dates are in UTC.
1 - Unique visitors per day - Including spiders
Hits h% Vis. v% Tx. Amount Data
------ ------ ----- ------ ----------- ----
14439 1.49% 1148 1.19% 106.42 MiB 21/Jan/2023
17043 1.75% 1754 1.81% 184.69 MiB 20/Jan/2023
33560 3.45% 3267 3.37% 491.32 MiB 19/Jan/2023
46568 4.79% 5816 6.01% 637.54 MiB 18/Jan/2023
323797 33.32% 28928 29.88% 4.06 GiB 17/Jan/2023 <- Resubmitted on HN and websites started copy-pasting the article from the big website with the same mistakes, never checking my post which had a note about these mistakes :)
24330 2.50% 3341 3.45% 360.48 MiB 16/Jan/2023 <- Put in a second-chance pool by a moderator and an article with a lot of mistakes published by some big website
17074 1.76% 3348 3.46% 243.44 MiB 15/Jan/2023 <- Published on HN
1041 0.11% 120 0.12% 3.70 MiB 14/Jan/2023
1666 0.17% 171 0.18% 8.40 MiB 13/Jan/2023 <- Post published
991 0.10% 123 0.13% 374.78 KiB 12/Jan/2023
2 - Requested Files (URLs)
Hits h% Vis. v% Tx. Amount Mtd Proto Data
----- ------ ----- ------ ----------- -------- -------- ----
57604 5.93% 31427 32.46% 260.97 MiB GET HTTP/2 /en/2023/01/13/msi-insecure-boot/
31179 3.21% 11263 11.63% 245.20 MiB GET HTTP/1.1 /en/2023/01/13/msi-insecure-boot/
11 - Referring Sites (depends on Referer header, not very accurate for reasons)
Hits h% Vis. v% Tx. Amount Data
------ ------ ----- ------ ---------- ----
446781 45.97% 29686 30.66% 5.95 GiB dawidpotocki.com
14834 1.53% 9485 9.80% 79.85 MiB news.ycombinator.com
(news sites with very low hundreds or even under, nobody checks sources)
What this is actually about: BlueSky is Jack Dorsey's new Twitter clone, it is eventually intended to be some sort of fediverse thing but it's not there yet and it's not the source of the fediverse gripes here. You can authenticate your BlueSky user as the owner of a given domain or subdomain by placing a certain file with a given content somewhere under that domain/subdomain. However that "somewhere" was just a location one of the devs at BlueSky chose, rather than somewhere relatively standardised, like under the ".well-known" path (which you might recognise from things like OpenID Connect where the configuration doc is located @ example.com/.well-known/openid-configuration). So one user exploited this and became the "owner" of that Amazon S3 domain by setting up a storage account on Amazon S3 and following BlueSky's setup instructions. That is the main story here - some non-Amazon rando is now officially the Amazon S3 guy on Bluesky.
The next part is that someone posted about it on this https://chaos.social Mastodon instance, which got overwhelmed, the owners decided to save their server by electing to return a 429 response for that specific post if users don't belong to chaos.social, and that is why people are upset about Mastodon.
Interesting story, but I'm not interested in Dorsey's version of Twitter 2.0 unless it actually allows you to signup[1] and brings something compelling that Twitter didn't and Mastodon doesn't.
[0] - game with an intricate story that does its damndest to not actually tell you. If you want to know the story you have to piece it together yourself by picking up dozens of items scattered throughout the game and reading all their descriptions. Or you can do what I did - watch a video on YouTube.
[1] - they're doing an open beta and letting a little trickle of users on, who post about it on their Twitter/Mastodon/whatever. Feels a bit deliberate, like they're trying to build anticipation and frankly I detest little manipulative things like that so I'm out
From the blog you linked, the number of interest is 18k. 12k are only those with HN referrer headers. In reality, many setup strips that header so you can't track it exactly right. The author did mention they averaged 50 views before.
A big part of it are reposts. From my own submissions, posting to HN resulted in tons of different origins. Public ones like reddit, twitter and private ones like newsletters, dashboard & chat messages. You'll also be surprised by the wide variety of clients people use to access HN.
They also used Google analytics to track the numbers. Most people in HN block it either through the browser or an extension [0]. In reality it's probably double the traffic.
Don't forget to account for scraping & crawling bots. That's another big source of traffic that the author didn't track.
[0] https://plausible.io/blog/google-analytics-adblockers-missin...
It's like all these newfangled webapps don't understand the concept of caching static pages for anonymous users. There is absolutely no reason that something like this should result in more than one request (plus a handful more for static resources) handled entirely by the frontent webserver's in-memory cache for each person linked from other sides. But instead its all dynamic and the page shoots off more API requests before being able to show anything.
> There's no stats page but last I checked it was around 5M monthly unique users (depending on how you count them), perhaps 10M page views a day (including a guess at API traffic), and something like 1300 submissions (stories) and 13k comments a day.
From my own understanding, the biggest useful differences for me personally is: account portability, domains as usernames and content-addressable from the ground up.
- Account portability - Useful if/when you want to move between servers
- Domains as usernames - Ties into the same value as account portability. I've owned my own domain for decades, it never changes and probably won't, until years after I die
- Content-addressable - Caching and syncing becomes so much easier, which is a huge issue Mastodon currently suffers from.
ActivityPub can identify users based on their domain too. Probably better than BlueSky does, because it uses better standardized mechanisms - the URI needs to dereference to a valid ActivityPub actor and the community has converged to using webfinger for discovery. The fact that web-finger is generally used for user discovery makes it easier to use the identical mechanism that BlueSky uses - where the identity (which in ActivityPub is a URL) is not tied directly to a domain. (Eg, if you do a webfinger query for marius.federated.id you will get a response where it tells you that one of the URLs for the ActivityPub identity associated with that is https://metalhead.club/@mariusor, you can check it out right now with curl https://marius.federated.id/.well-known/webfinger?resource=h...).
Account portability can exist in ActivityPub because the verbs for signaling to the network that an object/actor has moved to a different URL are in the vanilla vocabulary. The fact that nobody has implemented this so far does not make it impossible. (It's not like anyone so far needed to move from BlueSky to ... I don't know... BlueSky. So it being capable of moving identities is still equally theoretical in my view).
Regarding your last point (or the one made about it in the twitter thread), I don't really understand about how identifying content by its cryptographic signature is conducive to better caching and "syncing" (how in the world a hash would make it easier to sync content than a URL I don't know). HTTP clients, servers and proxies have very good caching and syncing mechanisms for anything that uses URLs to identify resources. Whatever BlueSky wants to do, must invent their own intermediary layers before anyone will be able to say "it's easier" with any certainty.
In my opinion nothing you mentioned can be called a "doing things wrong from first principals(sic)" - and I'm still hoping that linuxdude314 can make a better argument.
ActivityPub is fine for what it was designed to be: an exchange mechanism for "low impact" social activity. It's not meant to interact with cryptocurrencies, it's not meant to shelter dissidents from corrupt governments, it's not meant to help you interact with your drug dealer, nor whistle-blow on your employer. There are already options for those things. It is meant to allow your grandma to like your cat pictures in a more distributed manner than facebook offers. The people that imagine BlueSky will be doing something more than that, are - in my opinion - vastly overevaluating it.
(PS. Apparently this was not "similarly short", apologies.)
in an interesting coincidence, I found this today!