It's funny the bluesky devs say they implemented "something like webfinger" but left out the only important part of webfinger that protects against these attacks in the first place. Weird oversight and something something don't come up with your own standards

Maybe I'm old but what are some popular use cases for webfinger? (I'm just learning about it now)

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.

You'd hope that people doing job X would seek at least some insight into whether there are best practices for doing X, even if it's not a regulated job where you're required by law to have proper training. Not so much unfortunately.

Example: Many years ago now, early CA/B Forum rules allowed CAs to issue certificates for DNS names under TLDs which don't exist on the Internet. So e.g. back then you could buy a cert for some.random.nonsense and that was somehow OK, and people actually paid for that. It's worthless obviously, nobody owns these names, but until it was outlawed they found customers. But, even though the list of TLDs is obviously public information, some CAs actually didn't know which ones existed. As a result some companies were able to tell a real public CA, "Oh we use .int for our internal services, so just give us a certificate for like www.corp-name.int" and that worked. The CAs somehow didn't realise .int exists, it's for International Organisations, like ISO or the UN, and so they issued these garbage certificates.

[Today the rules require that publicly trusted CAs issue only for names which do exist on the public Internet, or which if they did exist would be yours, and only after seeing suitable Proof of Control over the name(s) on the certificate.]

I also recall /crossdomain.xml as an important one; allowing users to create an arbitrary file matching that name could allow certain kinds of cross-site attacks against your site.

Reader could have an optional Flash plugin, and better yet, you could configure the PDF interactive plugin to dynamically download the swf file to run.

I built an entire Flex based rich UI that was dynamically loaded by the 1kb PDF you’d receive in email, the Flex app retrieved and posted data via HTTP APIs.

Because reasons.

That product was live for years. I think we shut it down as recently as 2 years ago.

To be 100% clear, wasn’t my idea.

But it was my mistake to joke about the absurd possibility to build such a thing in front of some biz folks.

in an interesting coincidence, I found this today!

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 @[email protected]

Also the penalty isn't very high here. Someone impersonated a domain on a burgeoning protocol for a short while. So what?

We're talking about folks setting up a custom domain for a personal social media presence. If they can handle nameservers and DNS records, they can handle a folder with a dot in the name.

That's the problem with expecting people to agree with and follow standards.

You've effectively described what happens when people don't agree.

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

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

I'm not sure what Bluesky was attempting to do here but what they achieved in practice was allowing a user to claim control of a domain by claiming control of a page. But if you allow user generated content on the home page of your site, there's not a distinction (from a Mastodon user point of view) between the two. It's effectively the same problem if I can "verify" yourdomain.com on Mastodon - and my point is that you can do that without using .well-known.

If you allow UGC with *arbitrary HTML* or explicitly support generating rel=me. Both are you explicitly giving someone control of the site (or at least letting them claim they have it).

for 99.99% of cases when a domain is pointed at me and I want to serve an SSL certificate for it, I can answer an HTTP-01 challenge. Needing to orchestrate a DNS challenge will always be a more complicated external thing.

HTTP challenge (and TLS-ALPN) are in-band, DNS is out-of-band.

In contrast, HTTP based verification often has built-in support with your webserver (Caddy) or only requires copy-pasting a few lines to your docker compose file.

There are edge cases, but they're also widely exploited so you won't run into them if you follow best practices.

[1] https://github.com/joohoi/acme-dns

There's nothing preventing you from making the DNS record a CNAME to something under a zone that you're allowed to modify.

This is how one of my setups works; _acme-challenge.someservice.example.net is a CNAME to someservice.acme.example.net, and acme.example.net is served by a bind9 that allows dynamic zone updates based on TSIG-signed DNS update requests over WireGuard.

So the machine that hosts someservice has a DDNS key that signs DNS update requests for someservice.acme.example.net, and bind9 is configured to allow that key to change that record.

It's about proving /control/. If a domain name is pointed to me (my IP/CNAME) I control it and it is reasonable to allow that person to issue an SSL certificate for a domain (or subdomain) under their control. If you, as the domain owner, want to restrict that, CAA exists as your tool to do so.

But the reason for HTTP is pretty simple - it's extremely easy to implement. You only need to tell your ops to redir a subdomain to your app and you're done, you don't need DNS with API that have narrow enough permission to allow that one team in whole company to generate ACME stuff; most providers ACLs on DNS end at "this client have acesss to that domain via API".

Honestly, that's a feature, not a bug.

How many “low-impact” things have been compromised over the years, I wonder?

A company blog is a much bigger vulnerability when it comes to representing and verifying identity. Rather than let somebody fake identify to a computer system it allows faking identity to humans reading it. Yet I don't think most places require director signoff to post.

The economy demands no such thing. That's just the voice of greed in the tech bubble echo chamber.

No, it doesn't. There are plenty of businesses, and even entire industries that have operated for centuries on less than 2% growth. And yet somehow the world kept turning.

http verification proves you temporarily control IP space relative to a viewer. dns verification proves you temporarily control name resolution relative to a viewer.

Both are trivially hacked, multiple ways. By the time someone finds out you did it (if they closely monitor CT logs, which nobody does) you've already had hours, days, weeks to run a MITM on any domain you want. The attack only has to work once, on any of 130+ CAs.

The solution is registrar-level proof. Cert request signed by the private key of the domain owner, sent to the registrar to verify, the registrar signs it if its true, it's sent to the CA who can see the registrar signed it. Now you know for a fact the domain owner asked for the cert. The only possible attack is to steal all three of the owner's private key, the registrar's private key, and a CA's private key.

I have been shouting about this for 10 years, none of the industry incumbents care. The internet is run by morons.

> Both are trivially hacked, multiple ways.

I'm genuinely curious how it is trivial to "control [authoritative] name resolution relative to a viewer".

Whereas, if that required a signature from a private key, with a counter or other log of use in the TPM, it'd be caught by an audit without having to notice the symptoms.

I know that in security design that I've been involved with there's a lot more scrutiny given to each use of a privileged key than there is to making sure that all website logging lists each file in the directory at each request, or logging the full public state of your DNS every minute. Requiring a signed request makes the attacker come in through the front door.

The BGP attack requires knowledge of internet routing and the DNS attack requires knowledge of DNS server exploits, but either of them can be executed with very minimal network access that any consumer can get. Target the nameserver account admin with a phishing attack, account reset attack, lateral password bruteforce, etc.

You'd be surprised how incredibly stupid the admins of some of the largest computer networks are. It's really not hard to get access to some accounts. It should require more than just a username and password to hijack a domain, but usually it doesn't.

In any case, if all you want is a valid cert, you can do it a number of ways that nobody will notice. Again, this only has to work once, on any one of 130+ different organizations. Not all of them have stellar security.

And I'm not even talking about social engineering either the CA, Nameserver, or Registrar's support people, which I consider cheating because it's so much easier.

One problem I see is the extra overhead for the registrars. Now they have one more thing to do: verify (sign) certificate requests. That extra work is probably enough to get registrars to push back against such a system.

The registrar would be assuming some of the functions of a CA. This would make it easier for a single entity be both registrar and CA. That would threaten the business model CAs and thus they'd push back against such a system.

If the CA were responsible for getting the registrar's verification for a certificate request then that'd add extra work for CAs, and thus the CAs would push back against it. If the domain owner was responsible for getting the registrar's verification for a certificate before submitting it to a CA, then the domain owners would be against it.

And this is all assuming that people could agree on a common set of protocols or data formats for this new system.

I suppose I only take issue with "more" - as it stands don't registrars do effectively nothing today besides print money? It seems like the kind of business that doesn't require much that isn't already automated, and where the only reason I don't have a successful registrar business is that the contracts with whoever owns the actual TLDs are difficult to get. Perhaps they need to look out for DMCA letters? Idk maybe I'm way off, feel free to correct me if anyone knows it's a difficult job.

Or maybe, just maybe, hear me out on this... maybe your proposal is not as smart as you think it is.

For one thing:

> Cert request signed by the private key of the domain owner, sent to the registrar to verify, the registrar signs it if its true

What exactly does the registrar verify, and how?

The domain owner creates a CSR and signs it using their private key. Sends it to the registrar. The registrar uses the public key the user uploaded to validate the signature. This happens millions of times a day on shitty computers, this is completely old boring technology.

Now the registrar sends the Registrar-Signed-CSR back to the user. The user sends the RS-CSR to a CA. The CA uses the Registrar's public key to validate the Registrar's signature (exact same process as before). Now the CA can see the Registrar signed it, so it's legit.

Easy to automate. Boring old technology. Same flow millions of computers use every day, just with one extra party in the middle.

You're not wrong (ignoring how easy it is to hack DNS), but at the same time it's hard enough to get people to buy their own domain name, nevermind understand the system well enough to add a TXT record.

It's a strategy that's fine to implement when your target audience is server admins. It's a terrible strategy when your target audience is everyday users who you hope own their own domain. Doubly so in a world where owning your own domain is so rare for individuals.

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.

1. https://www.domainverification.org

And the primary way of identifying yourself is in fact DNS.

> I’ve been working on a solution to this

Your solution is almost identical to the BlueSky one: put a TXT record at _atproto.<domain> that resolves to a DID. The difference is that they mandate the DID spec and you do not. Which is totally fine! Just figured I'd let you know :)

Another key difference is that the _atproto TXT record is discoverable since it’s always at _atproto. Whereas the “verifiable identifier” I use isn’t discoverable because it’s hashed and used as a dns label.

The ultimate goal here would be for these records to be populated by domain registrars upon a domain being registered (with registrant’s permission obviously).

This could create a kind of fast lane for domain verification across providers like Google Ads, Facebook, Office365 and everyone else that requests DNS verification.

The worst thing is that hundreds of providers request domain verification TXTs at the zone apex:

dig target.com TXT

The official method is to set a TXT record, but apparently their "AT protocol" also lets you confirm a domain by serving `GET your.domainname.com/xrpc/com.atproto.identity.resolveHandle`

and `xrpc` was available as an S3 bucket name :)

Also to try to avoid having to special-case any logic in terraform etc.

Say you're working on a family of sites for tradespeople like plumber.io, electrician.io, carpenter.io, etc. A fair number of people from India have "occupational surnames" like Miller, Contractor, Builder, Sheriff, etc. Suddenly one Mr. Dev Contractor registers a bucket "contractor-dev" and you have to special-case your bucket names in your terraform.

Other things I think we do better on:

* The account is the top-level thing we publish a cert for. Without knowing the bucket name you can't really do anything. With S3's global namespace, each bucket has a cert published which makes all buckets discovered as soon as they're created.

* Not default open to the world

* The R2-managed public bucket cname is shared and the URL for the bucket is random (i.e. just a UUID). Additionally, if you delete and recreate the bucket with the same name IIRC that random UUID is changed.

* We have a lot of sensible extensions like automatically creating a bucket on upload (granted not possible for S3 since buckets are global), setting per-object TTLs, handling unicode more gracefully (I think normalizing the key name is a saner choice with fewer foot guns even if there's some potential compatibility issues when you try to synchronize from a filesystem where you have two files with different forms but same normalized), etc etc etc.

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!)

[1] If they ever actually turn off path-style addressing, come find me and I'll PayPal you a dollar. I don't think it'll ever happen.

https://www.zdnet.com/article/stop-the-lies-the-day-that-mic...

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

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.

I think the funniest one I struggle with all the time is “parallel.” I always think it should be “paralell.” I put the two parallel lines in the wrong spot in the word!

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.

I myself have had an account for like a month now, but only started really using it a week ago, because that calculus changed for me, personally.

Like, it's not even possible to truly delete posts at the moment. This all needs to be treated as a playground until things mature.

This isn't even the first "scandal" related to this feature already!!!! There is another hole in what currently exists that allowed someone to temporarily impersonate a Japanese magazine a few weeks back.

I have written atrocious bugs over the years, so I’m definitely not in the stone casting business here. However, I can’t see this as simply a bug, rather than a fundamental design flaw. And if an entity is both becoming infamous for reinventing the wheel, and attempting to fill a sensitive niche, I feel it has somewhat of an obligation to accept criticism such as that.

Okay this is exactly what I mean. How well do you know the AT Protocol? Because this comment seems to indicate you just learned about it from this link, yet you're still making grand claims like this.

This method of validating your identity isn't the primary one. It's not even documented! It was added two weeks ago, as an API endpoint to help serve moderation and administrative needs. Turns out the URL structure of the rest of the API is a bad call for this endpoint.

> and attempting to fill a sensitive niche,

If you want to criticize AT Protocol on privacy issues, there are far more important things that are closer to the fundamental aspect of the design to criticize.

A PR of "Change external domain validation to use .well-known (or DNS01, etc)" is not a "bugfix"

I'm not going to speak for the commenter you're replying to, but I don't think anyone here is talking about the standards-compliant, DNS-based domain verification system. I think we're all talking about the non-standards-compliant, /xrpc/-path verification.

Is there a public test suite?

The entire specification (which is admittedly incomplete) and implementation are open source.

I am not aware of a dedicated test suite for alternative implementations. It's too early, IMHO. I personally would much prefer the team to focus their time elsewhere for the time being.

They already build off of many related specifications, which have independent implementations, and a lot of the core protocol is RPC style, with schemas that they do publish. So there's already a lot of rigidity here for alternative implementations to use in a way that is extremely likely to be compliant.

I guess another way of putting it is "I don't exactly disagree with you but doing that takes work, and we're at the stage of this stuff where that work is being done, so expecting it right now feels premature to me." The spec isn't "released" or "done," it's in development.

The whole point was to start from scratch.

I'd be curious to learn about those.

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

But something I can answer directly to as I have deeper expertise with it, is this:

> how in the world a hash would make it easier to sync content than a URL I don't know

URLs are pointing to a location while content-hashes point to specific pieces of content. Moving from URLs to hashes as URIs gives you the benefit of being able to fetch the content from anywhere, and cache it indefinitely.

Basically any large distributed system out there, no matter if it deals with caching or not is built on top of content-addressable blobs, as it reduces the complexity by magnitudes.

Suddenly, you can tell any of your peers "Give me content X" and you don't really care where it comes from, as long as it is verifiably X. Contrast that to URLs which point to a specific location somewhere, and someone has to server it. If the URL is unresponsive, you cannot really fetch the content anymore.

Content-addressing used in this manner is not new or invented by Bluesky, but a old concept that has been used for multiple use cases, caching is maybe the most common one, but definitely not the only one. Probably the first time I came across it was in Plan 9 (Venti) around ~2000 sometime. First time I actually used it in production was with Tahoe-LAFS, which must have been around ~2010 sometime I think.

That is, I can just paste the URL for this article into my Mastodon instance, and if it has it, it'll fetch it from the local storage, if it doesn't it'll try to fetch it from the source, but there's nothing preventing a hierarchy of caches here, nor is there anything preventing peer to peer.

But while ActivityPub says that object id's "should" be https URL's for public objects, the basic requirement of ActivityStream is just that it's a unique URI, and there's nothing stopping an evolution of ActivityPub allowing URI's pointing to, say, IPFS or similar by content hash instead of a https URL.

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.

Most of the time, it's a good thing, but in cases like this is where this falls over.

(You can also see this in the other direction parent comment, for what it's worth, "Jack Dorsey's New Twitter" isn't really accurate, as far as I'm concerned. It is more informative overall, though.)

I am routinely down-modded and even banned for merely asking for more-descriptive titles. It's anti-user, anti-community, anti-usefulness, and douchey.

All we needed here was, at least, "Bluesky Social allows domain hijacking" or whatever it's actually doing (which I don't have a grasp of, even after following the cryptic link).

Or even just "This guy is now all of S3 on Bluesky Social." But that wouldn't be as click-baity, would it?

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

https://xkcd.com/2501/

their is who exactly? and why does bsky associate it with the s3 domain if it's just a file in a random bucket?

Aight, level with me: Is every mastodon server running on a Raspberry Pi?

Mastodon is also quite heavy to host, my single user instance will easily gobble up several gigabytes of memory if you let it. There are more efficient ActivityPub servers but specifically Mastodon seems to be written for running efficiently on huge servers.

> We just started serving a http 429 error on the exact url of the post. So everything should go back to normal now.

This is mind-blowing. Last I checked, the front page of HN sends tens of requests per second to each link. There are humans who can pack envelopes faster than the typical mastodon server can answer GETs. I'd love to see someone benchmark the top servers for a few seconds to see what it takes to break a reasonable latency SLA.

Probably messaging with pulsar and the build system from python 4, too.

I read this in a whitepaper. Let’s do this, guys! ;)

This message was federated to multiple servers efficiently and each of them is now serving it. What you're doing here is exactly not a federated service.

https://mastodon.social/@[email protected]/1103075321453803...

https://mastodon.sdf.org/@[email protected]/110308018473644...

https://universeodon.com/@[email protected]/110307532251412...

It looks like these links auto-redirect when I access them from here, but when you access them from the homeserver they are served without redirect. The content is accessible everywhere in the network.

"Works on my machine" isn't going to cut it for running a popular social network

Nobodies going to go around searching for mirrors, they'll just leave and go back to twitter

I don't really care how you implement your fediserve gimmick, I haven't received it. Seems like lots of people will not receive it either.

The one big change that I would like to see is for fedi to have its own URL scheme, because this URL doesn't need to point at chaos.social at all. Then you could open it on your home server.

If you just don't feel like signing up for a home server then it will always look clunky to you, oh well.

I've explained in other comments how a URL scheme would help with this.

There are many non-technical users on fediverse and it's working just fine for them, I see their posts all the time saying that they're having a good time. The problem in this case is HN users who aren't on the network anywhere, and there's not much I can do about that. I think if you were on it and had a home server this would not be that confusing, you'd just search for the post. Ideally you could skip the search step as well which is why I keep coming back to a URL scheme solution.

To understand how it's decentralized, search for @[email protected] on your own fediverse home server and the post will pop up.

There's a particular user story here which is a bunch of people who don't have accounts on any server, wanting to see the content from a central location (chaos.social). I do think it's worth talking about this story and ways to fix it but it's not really accurate to blame it on the federation behavior.

You can't post (because you're not logged in), so there's no issues with moderation. The toot is already federated publically, so there's no issues with unintentional read access. It doesn't need to contact the original server, so there shouldn't be any load/DDoS issues. I must be missing something…

https://calckey.social/notes/9ebxxsy83i

my profile, on the same server, loads fine.

I already don't trust mastodon links because 9 times out of 10 they simply don't work. Everyone's tiny hobby server falls over when one post gets big, and obviously not everyone is going to scale their servers to support the load of a viral post that might happen once every 6 months and will be 100x their base load

If someone sent any link or post that is from that Mastodon instance and it went viral, the entire instance will be sent to the ground and out for hours, making the post unavailable to be viewed.

The worst part is journalists and the media have to be told that posting a link from a 'small niche community' on Mastodon will send a flood of traffic that will knock it down offline also giving the impression to others that it is not ready for mainstream at all or even ready to onboard on tens or hundreds of millions of users, daily like Twitter.

Unfortunately there's no way to construct a link that references the post but opens where it belongs for you. I think there needs to be a fediverse URL protocol to solve for this, ie this HN post would link to `fedi://@[email protected]/110307532009155432`, then when people clicked it they wouldn't have to talk to chaos.social, because it would be opened at their home server.

Another option could be a 'copy link for public access' that generates a static page for the purpose of sharing widely.

Journalists and media could also run their own server which is scaled for the traffic they expect, and mirror the post there. The main problem is linking to the source of the post instead of linking to a federated representation of it.

> Most people don't even have a fediverse account ffs.

This is why you won't see a Bluesky post linked on HN, no one can open it. Imagine if you could sign up on your choice of thousands of servers and get the same access to the content rather than a central site, that's fediverse, it's not that complex.

As a community effort where no one is expecting to get rich it might work.

It's an annoyance, often anecdotal at most. Not the foundation of why a platform cannot ever "work".

https://hachyderm.io/@[email protected]/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.

This is peak Web 5.0 right here.

This person says they got 12k visitors over a day:

https://nicklafferty.com/blog/what-happens-when-you-re-on-th...

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

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

Some content is simply more interesting for a broader audience.

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)

Maybe you underestimate how many people want to keep up on things but not interact?

I can only see Mastodon centralizing to cope with the load. But a server going down on this load from HN tells us it is no where near ready to handle an insurmountable amount of users or even begin to challenge Twitter which hosts 220M+ users every single day.

https://pagespeed.web.dev/analysis/https-twitter-com-realDon...

Mastodon.social is actually much faster on this particular benchmark. So maybe there is hope.

There was a guy running a site off of a single core 32bit ARM SoC that was able to handle the HN frontpage.

https://leah.is/posts/scaling-the-mastodon/

Upon clicking reply fastidiously, i got the hn 429

"Sorry, we're not able to serve your requests this quickly."

Wow.

I'm sure just because of its age and principals involved it's been heavily influenced by the crypto crowd.

But suddenly, without anything else really stepping in to fill the void, it's the Twitter alternative of the day. Anyway not surprised to find some gotcha's like this all things considered.

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.

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

https://docs.joinmastodon.org/user/moving/

as others mentioned, not a hard fix.

the flexibility bit us on the butt. people started faking mentions via the APIs and one user figured out he could pack 1000 mentions into one "@everyone" and cause us all to get notified. pretty predictable in hindsight but I dropped the ball there

http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

Given that the AT Protocol is not compatible with ActivityPub, I don't see how the first step, let alone the second or third, is an accurate description of the dynamics at play here.

> And also how long until Twitter 2.0 or X app uses AT

Ironically, pre elon-buys-twitter, it did in fact look like Twitter was going to end up implementing AT, if all went to plan. But then post acquisition, if anything, that looks less likely.

edit: bsky.app links to blueskyweb.xyz so I guess so. weird.

"Death" of a product for one bug? ....

Yes, of course bandwidth is a concern, but then again there should be our way to monetize, and that's entirely possible using direct payments which already exist.

A little bit of cashing, CDN, and your phone as the initial file server. Tag a photo or video has shared.

Really it's just an RSS feed and CDN.

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.

At a previous company I worked at, every bucket had the company name prefixed. Never had a problem with squatters.

I wonder if Amazon actually has any policies to prevent squatting.

The ability to serve a file “www.example.com” in no way demonstrates ownership of “example.com”; it demonstrates that you control www.example.com.

If you want to prove ownership of a second level domain you must do it through a record in DNS, or through demonstrating control of something that is publicly known to control the domain such as the administrative contact emails.

This really is a solved problem in the PKI space; they should have borrowed that rather than invent their own.

Unless the UI makes it clear it was verified with "non-primary" methods so users can be cautious, any method of verification is essentially "primary" from the user POV.

* 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 @[email protected] 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.

I've read somewhere that federation is done via regular HTTP requests which ends up really hogging down servers if someone has a lot of followers.

So in the future, there may be more, hopefully more efficient choices.

[Edit: already mentioned above, I just misread it.]

Maybe the FediVerse is just not friendly to the idea of a “global top among thousands of users” rating.

Previously: https://news.ycombinator.com/item?id=34691489

It's not beyond the bounds of possibility. Compare https://github.com/mastodon/mastodon/issues/15431 .

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!

https://mastodon.social/@[email protected]/1103075321453803...

https://twitter.com/jonty/status/1653915932677271552

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 somehow and became the "owner" of that Amazon S3 domain by setting up an 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 like a deliberate thing to build anticipation and frankly I detest little manipulative things like that so I'm out

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.

I don't think I am equipped to diagnose what the root cause was here. It's even possible that this instance wasn't intended to have viral posts (i.e. high profile posts that get would get shared to many external users) and they didn't want to invest in hardware/services to facilitate this.

The question is whether the server was having issues with a flood of new posts being sent in and stored, or a flood of anonymous users clicking a link and blogging down when the same html was getting rendered over and over.

Knowing Mastodon, I have a bunch of was the latter with the server coming out on all the new data it was trying to store locally

Frankly this cynicism feels unwarranted. Bluesky is not a finished product — it is still being built and, even with the small number of invited users so far, there have been problems that have needed attention. The moderation story is still being developed, the feeds are still being tweaked, the app still has bugs, federation still doesn't work yet. Having some users makes for a valuable feedback loop but the team would rapidly become inundated and burnt out (and the platform would possibly turn into a wild-west hellscape with irreversible reputational damage) if they were to open the floodgates entirely at this stage.

Maybe that's in my head but layering this feeling on top of BlueSky being yet another microblogging service with a few other things that I don't love contributes to my impression of Bluesky being simply "meh". If it becomes the next thing that everyone uses, I'll inevitably have to check it out, I'm not going to be an early adopter though.

Mastodon is a shit show front to back. Even worse than corporate owned platforms.

Remember though that the war is a pretty delicate subject and that a position that from your perspective seems perfectly peaceful could be seen differently by others. So to a German the message "no weapons to Ukraine!" could be seen as de-escalatory, but to a Ukrainian it could be seen as a betrayal or it may remind them of bad faith pro-Z/Putin trolling even if that doesn't describe you or your intent whatsoever.

That’s good advice for a dinner party, not a valid defence of censorship on a social network.

If you want to just run your mouth and then complain about censorship when you get booted for violating someone's TOS or pissing off a mod, go nuts. No skin off my nose.

Even if a Go or Rust variant of exactly the same implementation would have been two or three times faster, it would not have survived the same onslaught. The way to survive that sort of accidental DDoS is not to change language but to improve algorithm choices where possible (where that makes a difference in order, not just a small difference in scale), make sure you are scaling efficiently over the CPU cores (possible in all those languages in various ways) available per node without busting memory limits, and by scaling out once that becomes a limiting factor.

This was effectively a DDoS situation (not an attack, but from the server's PoV there is no difference between a malicious DDoS and a hug-of-death from a mass of interested parties) and using Go or Rust instead of Ruby would likely have made no difference what so ever.

(the rest of your post is not discussing technical matters pertaining to the rest of the thread so I'll not encourage the off-topic-mess by responding in any detail, other than to say that sort of complaint wrt handling potentially contentious issues is common on social networks and not Mastodon specific)

I've not looked into BlueSky's domain based identity thing in any detail so I might be missing a point somewhere, but… If someone can manipulate its special location what would there be to stop the same someone being able to manipulate content under .well-known?

Are we just relying on .well-known having some extra protection (in this case by Amazon having created a bucket called .well-known so no one else could)? If so then .well-known is little safer than any other arbitrary location in this respect (because you are relying on every domain owner who might be spoofed to take an action to protect against this, rather than the protocol failing safe if nothing is done by the domain owner) and perhaps using DNS would be better.

If .well-known had just been invented, that would be true. It's fairly well established at this point, though. For example, if someone can create arbitrary files in .well-known, they are also able to pass http-01 ACME challenges and thus issue TLS certs for your domain (modulo CAA) and MITM you. At this point, allowing users to modify .well-known is about as good an idea as allowing them to receive mail for postmaster@ or accepting incoming packets from 192.168.0.0/16 into your LAN.

Amazon S3 specifically would not be vulnerable because bucket names can’t have dots in them; same for every other service that doesn’t allow those. Neither would services that prefix usernames with ~ or @ or similar, nor services that already use http-01 ACME challenges to get certs thus are already using that path.

I’d be much happier if proving domain control were only done through DNS challenges, but that ship has sailed.

Though MitM that way requires more steps than faking identity this way as you need to somehow get in the middle or redirect traffic towards you.

> I’d be much happier if proving domain control were only done through DNS challenges, but that ship has sailed.

Agreed.

-Post points out mistake in BlueSky's tech kind of comparable to "rolling one's own crypto" in concept (not as dangerous but not the kind of mistake one wouldn't expect that profile of an outfit to make) -Post is inaccessible because it's on mastodon and that specific mastodon instance seems borkd for whatever reason

All after lots of rage about twitter's tech being fragile in the sphere and probably going down any time soon as they fired most of their staff - but it's chugging along fine