Brain Dump - Lightweight AppView Impl.

The following design document is acting as a brain dump, there will probably be holes in whatever I was thinking a few weeks ago. Most of this is broad ideas and background information, little of it is technical.

Wording may be a bit weird because I used this in conjunction with AI to paste into a chat and get feedback. No generative AI was used to write this (hence the potential grammar mistakes).

Right now, one major critique of Bluesky (and by extension, the AT protocol) is that the AppView, where all data is aggregated from the fire-hose, is “centralized”. There is only one full-backfill AppView out there, and it is hosted by Bluesky PBC. The only alternative is mostly full-backfill but it costs the owner $200 USD a month, which is not maintainable. Plus, it’s not very stable.

Recently, I tried out Gotosocial, a light-weight Fediverse/Mastodon instance. My experience was alright, I found out how flawed the Fediverse/ActivityPub’s architecture is. Unlike the AT protocol, your instance has to find other instances. One method is following people. The issue is that no backfill is ran. My instance fetches the generic post count, join date, follower count, and following count and the pinned post. That’s it. No further backfill, only future posts, replies, boosts, etc they make along with new followers and following accounts. I didn’t like this approach mainly because it didn’t backfill even if I wanted it to (there wasn’t even an option to).

Another reason to decentralize, or at least empower users to use other AppViews, other than for the purpose of just general decentralization, is due to moderation. Bluesky can takedown any repository it wants on it’s own PDSes; and, they can even do this for repositories not on their PDSes. They can issue takedowns on their AppView, to hide repositories no matter their PDS. I understand why they do this (legal reasons, e.g. the user was posting illegal content), but it is still an issue especially with recent reports of the moderation team false-banning trans people.

There was a client a few months ago called Red Dwarf. This client completely bypassed the AppView, by using a service called Constellations by Microcosm. Basically Constellations provides an API which tracks backlinks. So, for example, you can quickly make an API request to find all the like records with a `.subject.uri` AT URI pointing to a specific post’s URI. Though, this can go for any type of record. All posts you saw in Red Dwarf were fetched through Constellation, and then fetched directly from the PDS. This is great in concept, though it does still have a centralized component. That being Constellation. Though, Microcosm is a group of projects made by one guy (in fact Constellation runs on one Raspberry Pi inside their home) so it’s not like they are a billionaire influenced by other billionaires.

My proposal is a system of both Red Dwarf’s creative system and Gotosocial but with backfill. What I think would work is that you can set up an instance log-in and then that account is set as the owner of the instance, then you’ll see your instance’s management panel. The instance will fetch the people you follow, and your likes. Then, based off your likes, it’ll identify hashtags you commonly like. From there, you can also manually add some extra hashtags, feeds, or users and then click save. If there is anybody or any tag you don’t want to be indexed, you can remove it. What the instance will do is listen to the Bluesky fire-hose, and if any events are created by the users you follow, are mentioning you, in a thread of yours/below a reply of yours, or include a hashtag you’re following, the instance will save the record creation/update/deletion to the database. By indexed, I mean all future events will be logged if they are with the Bluesky lexicon and past posts/replies will be fetched by downloading their .CAR file (will probably make backfill optional, and be a button for the instance owner). The .CAR file is small for most users, and all of their posts will be saved to the database, any replies will be saved but will be hidden 99% of the time due to the rest of the thread not being fetched. The rest of the thread will be fetched sometime, maybe. I’m not entirely sure about that.

This way, you don’t have to store the ENTIRETY of the ATmosphere or handle wide-scale AppView-level moderation just to decentralize from Bluesky PBC. You only have to store your network, or use someone else’s instance of this project (if I finish this project). This project would merge the federation system of Gotosocial, and of Red Dwarf/Microcosm’s Constellation project. This way you can still see every post with Microcosm, but still maintain an AppView of your personal network. You would own your data way easier, since it is still separate from the AppView with the PDS component, unlike Gotosocial/Mastodon/Fediverse in general which requires hosting everything just to own your data which in consequence means you have to own everyone around you’s data.