pds.dad / ceres
ceres: a small planet in a giant solar system
31
fork

Configure Feed

Select the types of activity you want to include in your feed.

ceres / README.md
at main 5.2 kB view raw view code
Bailey Townsend i can't spell
5f033497

Ceres#

Ceres is a "What if" experiment for me. A true put the rubber to the road and see if we can. We all know Bluesky currently has the largest app on The Atmosphere and it's very expensive to run mostly due to the data stored and queries needed to be ran on it. Ceres is an exploration of can we run a large atproto application like Bluesky cheaper with minimal backfill and some crafty caching without missing features. With that said it may be one day something hosted anyone can use, or it may just stay this mess of trying things out locally.

an image of the dwarf planet ceres

Ceres is a Bluesky AppView that aims to be easy on resources, does most of what Bluesky's AppView does (hopefully) with lower storage requirements, and can still make posts, reply, and comment, etc. But may be missing things like full counts, some links, and search. Not that I won't try, just starting simple.

Ideas/goals to explore#

  • 1:1 compatibility with Bluesky's AppView. What I mean by this is you can find and replace did:web:api.bsky.app in any social-app fork and get a working AppView. May not be complete, but it will work in some capacity to spec of the app.bsky.* lexicons
  • How much can we get away with loading directly with microcosm's tooling. Slingshot and constellation mostly
  • Cache heavily and use the firehose to invalidate cached entries and re hydrate
  • What does the storage requirements look like if the backfill is limited to hard to get counts like followings, posts, relationships, etc.
  • Can we keep proper counts with the firehose once an account has been backfilled.
  • Does it make sense to backfill at a community level, then run on demand for the rest. Aka blacksky.app, northsky.social, eurosky.social, etc.
  • Can you backfill dynamically and on demand. Example, First time the AppView seen a did it fills in the missing bits of it's information and watch for new updates
  • Can this all be done in a single binary with embedded storage? May not be able to serve millions. But if 100s can be set up easily and have the same view do you need to serve millions, or just one for your community?
  • Will this be what finally forces fig to move constellation off of the raspberry pi?
  • A small thing. But I had what I thought was an awesome idea to have a catch all endpoint that prints the url, queries, and body of the request so I can track what endpoint to work on first. Is this a good approach at reverse engineering an already built application

Work done currently#

  • app.bsky.actor.getProfile - Just started, and let me tell you. It got hands
    • Should be pulling in everything from the profile lexicon
    • Loads images in via getBlob, will also most likely have a CDN flag
    • Pulls in followers since it's easy from constellation
    • labels are not there yet, but plan to pull them in. atproto-proxy requests has a header with the did's for the libelers the user is subscribed to. Plan isgrab via the headers -> query the labelers -> cache heavily
    • Other things like labels, etc are not done yet
  • app.bsky.actor.getAuthorFeed
    • It "works" it loads in the feed and maps most things properly like making sure embed views of pictures and links are right
    • Does not have any counts yet like replies, likes, etc.
    • Is not returning filtering as expected. Example on the posts page it does not show the expected feed of posts and reposts, but includes replies since it's walking the collection atm and no caching

Preferences are, well. A pain. I started to implement them since because of the age gated stuff they're kind of a need from any vanilla fork of the Bsky social-app. Long story short. They're stored in the PDS, it's easier to not have your own "prefs" if you are building a Bluesky Appview and to just clear the atproto-proxy header and grab those from the PDS via the social app than have your own. Will most likely yonk these endpoints or return a message like "can't do that".

  • app.bsky.actor.getPreferences - Works, but not as expected. It has it's own internal preferences. Not the ones from your PDS. best to just use a social app that clears the atproto-proxy to get from your own PDS
  • app.bsky.actor.putPreferences - lol. Best to just use a bsky-social app fork like https://blacksky.community for running this AppView

Does it even work right now?#

Kind of? The most feature complete endpoints atm are the app.bsky.actor.getProfile and app.bsky.actor.getAuthorFeed which allows me to load the profile page in a social-app, like below in a local fork of blacksky.community.

You can see that it is loading in my profile pictures, as well as details from my profile record, as well as my posts below that. But some counts like following and posts are funny numbers, or empty. This is because those are not as easy to grab without a backfill of some sort.

The current plan is to get what I can from constellation and slingshot, then see about what else I can backfill for things like relationships between records, counts, and labels. Also a fun tidbit.

profile example