GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Embed Notice

HTML Code

Corresponding Notice

  1. Embed this notice
    Rob Ricci (ricci@discuss.systems)'s status on Friday, 17-Apr-2026 10:34:26 JSTRob RicciRob Ricci
    in reply to
    • bryan newbold
    • Jon

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

    In conversationabout 6 months ago from discuss.systemspermalink

    Attachments


    1. No result found on File_thumbnail lookup.
      Rob Ricci (@ricci@discuss.systems)
      from Rob Ricci
      With bluesky (mostly) going down for a few hours today, I got to wondering about how decentralized the fediverse really is in terms of where its servers are hosted. I grabbed a server list from fedidb, with network information coming from ipinfo.io . [EDIT: I did a better analysis on a dataset of 10x as many servers, see https://discuss.systems/@ricci/114400324446169152 ] These stats are by the number of *servers* not the number of *users* (maybe I'll run those stats later). fedidb currently tracks 2,650 servers of various types (Mastodon, pixelfed, lemmy, misskey, peertube, etc) The fediverse is most vulnerable to disruptions at CloudFlare: 24% of Fediverse servers are behind it. Also note that this means that I don't have real data on where this 24% are located or hosted, since CloudFlare obscures this by design. Beyond CloudFlare, the fediverse is not too concentrated on any one network. The most popular host, Hertzner, only hosts 14% of fediverse servers, and it falls off fast from there. Here are the top networks where fediverse servers are hosted: 504 Cloudflare, Inc. 356 Hetzner Online GmbH 130 DigitalOcean, LLC 114 OVH SAS 56 netcup GmbH 55 Amazon.com, Inc. 55 Akamai Connected Cloud 36 Contabo GmbH 33 SAKURA Internet Inc. 32 The Constant Company, LLC 31 Xserver Inc. 28 SCALEWAY S.A.S. 24 Google LLC 23 Oracle Corporation 16 GMO Internet Group, Inc. 14 IONOS SE 14 FranTech Solutions 11 Hostinger International Limited 10 Nubes, LLC Half of fediverse servers are on networks that host 50 or fewer servers - that's pretty good for resiliency. There is even more diversity when it comes to BGP prefixes, which is good for resiliency: for example, the cloud providers that have multiple availability zones will generally have them on different prefixes, so this gets closer to giving us a picture of the specific bits of infrastructure the fediverse relies on. The top BGP prefixes: 55 104.21.48.0/20 50 104.21.16.0/20 48 104.21.64.0/20 41 104.21.32.0/20 41 104.21.0.0/20 38 104.21.80.0/20 32 172.67.128.0/20 31 172.67.144.0/20 28 172.67.208.0/20 28 162.43.0.0/17 27 104.26.0.0/20 26 172.67.192.0/20 26 172.67.176.0/20 23 172.67.160.0/20 19 116.203.0.0/16 17 172.67.64.0/20 17 159.69.0.0/16 16 65.109.0.0/16 14 88.99.0.0/16 14 49.13.0.0/16 13 78.46.0.0/15 13 167.235.0.0/16 13 138.201.0.0/16 11 95.217.0.0/16 11 95.216.0.0/16 11 49.12.0.0/16 11 135.181.0.0/16 10 37.27.0.0/16 10 157.90.0.0/16 75% of fediverse servers are behind BGP prefixes that host 10 or fewer servers, meaning that the fediverse is *very* resilient to large network outages. Top countries where fediverse servers are hosted: 871 United States 439 Germany 156 France 148 Japan 75 Finland 57 Canada 49 Netherlands 38 United Kingdom 26 Switzerland 26 South Korea 21 Spain 19 Sweden 18 Austria 17 Australia 15 Russia 12 Czech Republic 10 Singapore 10 Italy And finally, a map of the locations of fediverse servers: https://ipinfo.io/tools/map/91960023-e8c6-4bee-9b07-721f2c8febab
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.