Skip to main content

Search

Items tagged with: atprotocol


From a preliminary ~12h sample of #bluesky / #atprotocol , a small number of accounts receive most interactions. This is an obvious byproduct of the way the default algorithmic feed prioritizes posts.

- 5% of accounts received 72% of likes, 1% of accounts received 41%
- The top 5% of accounts make 48% of posts
- 37% of accounts receive no interaction
- The median account received 1 like.

Just a quick, incomplete look, but ya looks like an engagement farm
Line graph showing the cumulative sum of likes on the y axis vs. accounts on the x axis. Vertical lines indicate different quantiles of likes per account (0.25, 0.5, 0.75, 0.9, 0.95, and 0.99)

The line hovers near zero for the first two-thirds of the graph, but starts to increase around the 0.75 quantile. at 0.9 it is at ~100,000, and then the line rises sharply to its maximum at ~450000 through the 0.95 and 0.99 quantiles. 

If the network was "flat" where everyone received the same amount of interaction, the line would be a straight, diagonal line. The amount of convexity in the line indicates the degree to which the network's interactions are concentrated on the top accounts.


#Bluesky / #ATProtocol is an extremely funny protocol that is explicitly designed to ensure that there are still powerful entities that own your attention. Sure! you can host your own personal data store, but everyone else will be getting your posts through a Big Graph Service that necessarily crawl all posts on the network, so it's actually mostly irrelevant.

https://blueskyweb.xyz/blog/5-5-2023-federation-architecture
Network diagram showing data flow in the bluesky network.

Individual users interact with personal data stores (PDS). Those PDS are crawled by Big Graph Services (BGS). BGS then feeds posts to AppViews and other feed generation services. Those feed generation services feed other posts back to your personal data store.


lmao taking a look at #ATProtocol / #Bluesky's implementation of #DID, and I think they missed the "decentralized" part in their "placeholder" DID method.

Your domain's DNS entries just contain a (truncated) hash that then has to be resolved at plc.directory

recall that the DID method (plc) is part of the DID, so a different method (eg. web) is a different DID. to switch, you'd need to set an alsoKnownAs entry. plc only supports AT handles for alsoKnownAs.

https://github.com/bluesky-social/did-method-plc#did-resolution
DID Resolution

PLC DIDs are resolved to a DID document (JSON) by making simple HTTP GET request to the PLC server. The resolution endpoint is: https://plc.directory/:did

The PLC-specific state data (based on the most recent operation) can be fetched as a JSON object at: https://plc.directory/:did/data