Untitled attachment

Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Sunday, 28-Jun-2026 12:54:43 JST

@futzle this is embarrassing, but you don't actually have me blocked.

I want to let you know that we use a form of privacy-respecting boost that does not share your content with servers or people that you block.

So, no, your content won't go to servers you have blocked.

There is an open ticket here to add a blocklist like cariad's DNI list for the worst of the worst:

https://github.com/evanp/activitypub-bot/issues/115

Embed this notice

Rob Ricci (ricci@discuss.systems)'s status on Friday, 17-Apr-2026 10:34:26 JST

Rob Ricci

in reply to

@jdp23 @bnewbold

Thanks very much for these thoughts! I really appreciate your help and patience filling in the gaps in my knowledge here. FWIW I'm playing around with these things hands-on to learn more, I set up my own PDS last night and hope to try my own relay, either with the reference implementation or blacksky's rsky this week.

On PLC: The number of did:web handles for the network appears to be - according to another dataset I found that scrapes handles - 159. I'm not confident in saying that's the complete set, but the number of PLC handles would appear, conservatively to be north of 99.9% (the dataset I am using, which is coming from the bluesky relay, contains 402k handles, so that's assuming that I'm seeing a representative sample of the full set of handles)

My conclusion here is that the B-Index for atproto is, depending on your viewpoint, very boring or very revealing. Unless the handle data I'm looking at is very incorrect, the B-Index for the *current* atmosphere is effectively $B_X$ = 1 for all $X$ at least up to 99.9; whether or not you believe they *would*, through administrative decisions or company failure Bluesky PBC could cut off any or all users from 99.9% of the network. I'm sure some people find that totally unsurprising, while others are probably quite surprised.

On your third point, this is actually kind of what I'm trying to capture with B-Index. Yeah, it does seem like (maybe other than the PLC) that someone who is using blacksky's appview, PDS, and relay, is going to be just fine within the blacksky network - but they will be cut of from 99.999% or so of the atmosphere. The B-Index is not trying to model whether they care - some people will be perfectly fine with that scenario, but rather model the centralization of power that gets one to that point; ie. one company can decide to cut me off from 99.999% of the world, vs. if m.s blocks me (worst case on the fediverse) that cuts me off from 25% of the world.

On the Mississippi situation, my answer is kind of similar: how many companies (or instance admins, etc.) does it take to make a decision that affects X% of users. On the VPN thing, I think we can't model it, since we can't really model the how accessible VPNs are. On the alternative appviews, we can, though, if we can get user counts for them; here the B-Index may be higher, because more entities have to make the decision to block.

So some other thoughts here:
* One of the interesting things (I hope) about B-Index is that you can use it for little 'what if' experiments, eg. we could move on from the PLC, assume that it will not be used to revoke DIDs and that it will not go down, move on to the next 'largest' resource and go from there: I assume that's likely to be the bluesky relay or maybe the appview. But this is where I need to understand better what someone on, say, blacksky, who has been banned at the appview and/or relay level from bluesky can or cannot see. Maybe once I have my own relay to play with I'll have a better understanding.

* I think it would be interesting to create some version of this metric that looks not at blocking but credible exit, separately for social graph and user data (which as you point out is going to cover an exceedingly small number of Fediverse users today). Though it sounds like atproto might run into the same problem with PLC - but we can use the same technique of 'here's what it looks like today, here's what it would look like if the PLC were in the hands of a consortium, or truly decentralized, etc.

* Labeling and feeds are also going to be interesting here, I'm not giving up on trying to look at those just yet :) This will probably be the case where, assuming I can get appropriate data, the *fediverse* is the one that's complicated to model, since each instance has its own blocked

* As you point out there are DNS and other external dependencies, and I'm interested in those as well, I did some rough numbers for the fediverse in terms of networks that hosts are on a while ago, I'm sure this could be formalized: https://discuss.systems/@ricci/114396317436420669

* I think it would be interesting to extend the kind of thing noted in my previous point to legal jurisdictions as well.

Embed this notice

Patrick (patrickoftheg@mastodon.social)'s status on Tuesday, 03-Feb-2026 04:22:48 JST

Patrick

@FlashMobOfOne See, the thing is from my perspective, God isn't all powerful and God definitely isn't all good.

Just the biggest bully on the block.

So you have to make do.

I'd be happier if I didn't believe in God.

Embed this notice

Rob Ricci (ricci@discuss.systems)'s status on Monday, 28-Apr-2025 07:43:27 JST

Rob Ricci

in reply to

🧵 2/2

IANA is administered by ICANN: https://en.wikipedia.org/wiki/ICANN . Again, ICANN is an international organization, but its headquarters are in the United States. I would compare this to the United Nations, which also has its headquarters on US soil. Yes, the US could put the organization's property and some of its personnel under threat, and it could be quite disruptive, but the organization is global enough that it almost certainly could continue its operations and maintain its desired policies under such an attack.

Let's also talk about the physical infrastructure at the root of the DNS. When you look up example.com, your DNS resolver (conceptually) goes to the root to ask where the DNS servers for .com are, then asks those servers where the DNS servers for example.com are. These root servers are extremely important, if utterly invisible to most people. There are currently thirteen root DNS servers: https://en.wikipedia.org/wiki/Root_name_server . However, each 'root server' is actually a bunch of root servers, many of them spread across the globe in various countries. The picture attached to this post shows where the physical servers are. Most of the operators of the root servers are American companies, but there are also companies headquartered in the Netherlands, Sweden, and Japan. We are probably pretty safe on this front.

Let's wrap up by moving a level up, to the DNS server closest to your own computer.

Unless you've done any special configuration (and you will know if you have...) you are probably using either one two DNS servers: most devices and software on your network are probably using your ISP's DNS server, and your browser *might* be using a third-party DNS server via DoH.

Could a government compel your ISP to hijack DNS requests? Legally, I don't know, but on a technical level, mostly yes. Doing so would involve adding entries to their DNS servers that differ from the "real" ones, and returning those to you instead. This would essentially hijack the domain for all customers of that ISP. An attacker would have to do this ISP by ISP; this is easier in some places than others - in some countries the ISPs are already functionally arms of the government, in others they are independent but have consolidated down to just a few options, and others have more diversity.

Ah, but, you say, DNSSEC! And yes, DNSSEC! For most of its history, the DNS has not provided a way to verify that the answer you get is legitimate instead of, say, replaced by your ISP as described above. Some time back, a set of extensions to DNS was put together to prevent such attacks: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions . There is more detail here than I could possibly go into, but this mechanism is (1) deployed on some TLDs but not all, (2) deployed only spottily on domains within the TLDs that support it, and (3) not universally checked by all resolvers. So: yes, DNSSEC helps - it generally protects the domains that have deployed it from being hijacked, even under threat to the ISP, but its effects are uneven.

ISPs can relatively easily block you from using DNS servers other than their own - AFAIK, most don't, currently, but they can, because DNS requires UDP port 53, so it's easy to recognize and block.

So, let's talk about DoH - this is DNS over HTTPS, and it gives you an encrypted way to make DNS requests and uses the same TCP port as HTTPS, making it harder for an ISP to block. Like DNSSEC, the more DoH there is in use, the less effective ISP-level domain hijacking is. Lately, browser vendors have started experimenting with making DoH the default for at least some users in at least some places; both Firefox and Chrome turned it on by default for some users in 2020: https://en.wikipedia.org/wiki/DNS_over_HTTPS . But, this is not 100% a win for freedom from government attacks: Chrome uses Google's DNS servers by default, and Firefox uses CloudFlare's - this can be changed, but it's a re-centralization, and therefore an attractive attack target for governments that have leverage over these two organizations.

So to conclude: the DNS is a very messy system with lots of points that could be attacked by a government, but it is also comprised of enough systems, organizations, and protocols that attempts to seize domain names are likely to be hard to do at scale, and while the opportunity for mass disruption does exist, it is unlikely to meet with much long-term large-scale success.

Embed this notice

Futurist Jim Carroll (jimcarroll@futurist.info)'s status on Monday, 17-Apr-2023 08:55:48 JST

Futurist Jim Carroll

in reply to

@davidaugust Well, I must contradict!

I have my own company and run my own server for myself.

I sure as heck can break it if I do something bad in su. Or mess with some init scripts. Or wipe out my carefully crafted nginx block.

So, one person and one company can break one.

(-;

Public

Notices where this attachment appears