an appview-less Bluesky client modeled closely after some of the best implementations of social media goungle.oat.zone/
bluesky client atproto
1

Configure Feed

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

TypeScript 79.1%
CSS 19.6%
HTML 1.1%
Shell 0.2%
37 1 0

Clone this repository

https://tangled.org/oat.zone/goungle https://tangled.org/did:plc:f35eggbxfys7gzuqxd7zxai7
git@tangled.org:oat.zone/goungle git@tangled.org:did:plc:f35eggbxfys7gzuqxd7zxai7

For self-hosted knots, clone URLs may differ based on your setup.



readme.md

goungle#

an appview-less Bluesky client modeled closely after some of the best implementations of social media

Notes & design#

right, so what exactly does that mean

Bluesky client?#

I'm a pretty big fan of Bluesky - all my friends have generally settled there, and due to the open nature of it I'm not too concerned about enshittification making it an overly hostile place to stay on. generally, this is where I've decided is safe to settle for the next couple of years, or maybe even more if the open nature of the protocol comes to fruition.

there's just one issue - Bluesky, the website, the app and the company - all suck massive fucking balls

time after time again Bluesky PBLLC have proven that their developers generally don't have much of a care for their userbase12 outside of their current main userbase of resistlibs, atproto vibecoders and associates. and I mean I guess that's fair, it's not like they chose their current userbase - but that does mean staying on the website is a bit of an uphill battle. but like, it is an open protocol, so like, you can just kind of do mostly anything with the actual data stored and hosted on the PDSes, right

Open protocol?#

Bluesky, the social media, is powered in large by the AT Protocol. it's a federation-like conglomerate of officially and self-hosted servers, relays and tools communicating and federating with eachother. if it doesn't feel like Bluesky is federated in the sense that something like the Fediverse - that's because it isn't, and I actually feel like that's a benefit to ATProto. when Bluesky was originally picking up steam, I was really hesitant to join because after being a Fediverse user for a while and then not being a Fediverse user for a while longer it felt obvious the shortcomings of federation were far too great to build a competent social media on top of. and well, I've been proven wrong - ATProto has proven itself as a really good protocol to build apps like Bluesky on top of. the actual federation aspect of it is mostly invisible in practice, but does in fact prevent one central party from being in control of all content on the website. well, almost

a few layers stand between using Bluesky, the app, and actually being free of Bluesky PBLLC's control, those being the officially hosted PDSes (colloquially known as mushroom PDSes), the PLC directory, and app views. PDSes are easy to switch between and easy to selfhost, making that a solved problem; the PLC directory is something far greater than me for me to tackle (and did:web partially helps with it3); and app views are, well... hm

App views?#

app views are a type of indexer / filtering / comprehension service that basically scrape data from PDSes and relays and turn it into usable networks to build full apps on top of. when a user wants to get feeds on their timeline, their client shouldn't fetch every post published by their followings, sort them by publishing date, fetch every like record for those posts, so on and so forth - that'd be wasteful and also just really impractical. app views alleviate this by doing the work of indexing as a service for clients to then interact with. a client can ask an app view for posts, and the app view will already have the people who liked that posts available for them in a neat list or count.

the issue is trust, however - while you can know for sure the app view isn't giving you wrong info by just checking in with the PDS, you can't trust what the app view isn't giving you. and the Bluesky app view frequently does app view level takedowns of accounts, posts, and so on - effectively acting as an unremovable moderation layer

Aside: why not self-host an app view?#

this is a really good idea in theory but in practice falls apart because the app view does a lot of heavy lifting when given the scale of the entirety of Bluesky - so much so that Bluesky PBLLC themselves are really the only ones with the resources available to host an instance of the Bluesky app view. Blacksky tries to offer an alternative app view, but from my experience it is extremely evident when using it just how lacking it is in power to actually give the full Bluesky experience. some profiles won't load, some identities won't resolve, some posts are missing - and I'm sure they'll iron it out with time, but this is always going to be a constant problem with hosting an app view

and also, well, now you're relying on Blacksky instead of Bluesky. great going on that one

Appview-less client?#

if you've been around the ATProto development scene for long enough, you'll likely have heard of Red Dwarf - the client that, for the most part, doesn't use the Bluesky app view, or any app views for that matter. it does this by fetching data directly from the PDS and by other, more lightweight community-run indexing services that are much less motivated to be making takedowns of content or such.

it's a really impressive piece of tech (and this project references a lot of its inner workings) - but with great respect to the developers, you can't really call it more than a toy. it's missing many features, has quite patchy design, and most importantly is just a Bluesky client in the most literal sense, borrowing all of its design and implementations. I don't really agree with most of its decisions as a standalone social media app, and I guess in summary what this project is is a better version of Red Dwarf further aligned with my visions for a social media website.

Prior art#

after being a Twitter, Fediverse (Mastodon, Glitch-Soc, Akkoma, Misskey), Tumblr, Cohost and now Bluesky user, I'd like to think I have a pretty good idea of what's best for me in a social media website. I think the following are pretty great ideas:

  • Twitter's general style of spitball posting is great. I like reposting things. quoting is a neat feature, but implementation of it in most Twitter-likes is faulty. I also enjoy others seeing that I liked their reposts. this works really well on porn alts
  • Fediverse's instance drama has taught me exactly what federation shouldn't be like - this client (and hopefully the tooling that powers it) will never restrict you from seeing others or other parts of the network based on moderation decisions you personally don't sign up for. Bluesky alleviates this a lot with labellers, and the intent with this client is that you rely on those for your general-purpose moderation; otherwise, you alone curate your feed and who you block or don't block
  • Tumblr (and later Cohost)'s model of reblogs is something I greatly prefer over Twitter's quotes - putting the quoted post in a smaller frame below the quotee inherently creates a power dynamic where you're more likely to skim over the quoted post. this is pretty unproductive. also I just prefer reading the quoted post first most often anyways, and this lets me do that easier
  • Cohost's no-metrics is great and taught me a lot about how to actually have fun on social media as a person with perfectionism and RSD - these days, on every other social media website I frequent (Bluesky included), I'll always have some extension or userstyle to hide metrics. there is no reason you should need to see the exact count of people liking each individual post of yours it just fucks with your head and makes you seek engagement over genuine posting

this client is mostly a combination of all of the above in one combined package of the best of these. I think the combination is neat

What does "goungle" mean#

https://bsky.app/profile/did:plc:v2aepp7z7sniw2atmupbpy6a/post/3moycfvzguk2n

Implementation details#

the flow of data and what's fetched from where can be viewed in detail in data.md - but in summary, it's mostly microcosm service calls (constellation, slingshot) and direct PDS calls. some things still require an app view but I don't believe they'll ever be much of an issue, and are extremely hard to replace

Development#

goungle is a plain HTML/CSS/JS application (well, almost, there's TS instead of JS). this does mean that all of the DOM manipulation also happens with regular JS. this probably sounds awful to some, but I've gotten used to it and like the amount of control it gives me.

you can get started with a development copy by cloning the repo and using the Vite dev script:

git clone ...
pnpm install
pnpm dev

then bundle it up and get it ready for deploying with build:

pnpm build

  1. https://bsky.app/profile/did:plc:z72i7hdynmk6r22z27h6tvur/post/3mk4lzkrnk22d ↩︎

  2. https://bsky.app/profile/did:plc:z72i7hdynmk6r22z27h6tvur/post/3lz7yasblh22p ↩︎

  3. I heavily disagree to the solution of "one central party has control over everyone" being "then make yourself the central party". not everyone is a developer or sysadmin, not everyone owns a domain, and not everyone wants to rely on themselves for a social media site. this is just the Fediverse all over again ↩︎