alnkq.bsky.social
Software dev. Interests: .NET, compilers, performance, DuckDB, ATProto
I'm building AppViewLite, a self-hostable appview for Bluesky
https://github.com/alnkesq/AppViewLite
125 posts
386 followers
30 following
Regular Contributor
Active Commenter
comment in response to
post
By default, it only listens to mod.bsky.app, but if you set that env variable to *, it will listen to all the labelers listed in the PLC directory
comment in response to
post
Note that this is not another discovery feed. The balanced feed still only shows you content from the people you follow, or that they directly repost.
comment in response to
post
If you're particularly fond of a certain user or set of users (based on your interactions), it will make sure that you don't miss out new content from them, even if they post from a different timezone.
comment in response to
post
It still tries to favor recency, but not at the cost of being too repetitive.
For example, it clamps the number of consecutive posts or reposts from the same person at any given time, as well as the number of reposts of content from people you don't follow (the maximum ratio is 3:1)
comment in response to
post
Depending on how you configure it, it can fetch the blobs lazily from the PDSes (and possibly cache the thumbnails to disk), or it can reuse an existing CDN (cdn.bsky.app)
comment in response to
post
That would mitigate the inner loop.
But to be honest I don't even remember how long it takes, I ran the generator only once some time ago.
I just know that it produces quite a lot of code.
comment in response to
post
The worst ones are those that don't even bother fetching the OpenGraph preview
comment in response to
post
It might be a nice coding exercise, but the amount of generated code is quite big.
Having the generator run manually and predictably and only when you actually need it is probably better from a development experience point of view.
comment in response to
post
AppViewLite reuses the FishyFlip generated types.
@drasticactions.dev is also working to add support for generated AspNet XRPC server API stubs (and I'm migrating appviewlite to use them)
comment in response to
post
...and Telegram channels
comment in response to
post
The AppViewLite native UI works for sure, for creating posts.
Deer + XRPC appviewlite, I never personally tried this combination, so I was a bit surprised to see that it just worked.
comment in response to
post
Yes the native UI is more feature-complete compared to the social-app + XRPC combo
comment in response to
post
The mismatching CIDs suggest that you were actually using appviewlite.
The quote works fine because not even bsky.app cares if CIDs mismatch (I wasn't expecting that)
comment in response to
post
So the post was actually made via appviewlite, since it has the fake CID (hash of the AT URI)
comment in response to
post
This post (3lo7cgbwztk2y) has a CID of bafyreiawog47kaoyh2mwzf253botysanebpqllpah3nrxb34jvwlbatbgq, but according to phil's quote of it allegedly made with appviewlite (bsky.app/profile/bad-...), it's bafyreic2kah5bvujxnaxaq44di22mloiprmu456pehex575iok674mbxh4 (which is different).
comment in response to
post
AppViewLite doesn't even currently keep track of CIDs, they're just temporarily fetched when you perform a quote, like or repost (when using the native UI).
I was surprised that phil was able to "quote" a post, given that he used XRPC (which is currently readonly and returns fake CIDs)
comment in response to
post
That's probably unrelated. Things should work fine even with an out of date PLC directory (if a handle is needed that is not synced yet, it will be queried directly from plc.directory)
comment in response to
post
Also the way I ran social-app on top of appviewlite yesterday was by changing social-app to send requests to appviewlite
(social-app -> appviewlite), instead of (social-app -> PDS -> appviewlite).
I'm not sure what deer social does instead
comment in response to
post
With /xrpc requests, the session is handled exclusively via Authorization: Bearer
With every other request, the session is handled exclusively via Cookie: appviewliteSessionId=...
Do you see that error when trying to log in via AppViewlite native UI, or via Deer Social?
comment in response to
post
What does your appviewliteSessionId cookie look like?
It should be something like
32alphanumericsecretchars=did:plc:xxxxxxxxxx
Are you using a custom PDS implementation?
comment in response to
post
The README probably needs instructions on how to set up a reverse proxy.
I haven't personally done it since my instance is not served over the internet.
comment in response to
post
I see that some generated links are broken (Search -> Posts/Media/People/Feeds), they link to 127.0.0.1
Is your reverse proxy forwarding X-Forwarded-For / X-Forwarded-Host etc? learn.microsoft.com/en-us/aspnet...
comment in response to
post
The stacktrace looks cropped so I can't see where the bad DID is coming from. But if it's from the PLC directory sync then it should be normal (the PLC directory contains some garbage/fake values)
comment in response to
post
So at the current growth rate, it takes 1 TB per year for full network data.
I added some optimizations (APPVIEWLITE_ADDITIONAL_DATA_DIRECTORIES and key index cache) that should make it feasible to move old rarely used slices of the database to slower but cheaper mechanical harddisks
comment in response to
post
No, so far 196 GB (only since Feb, not backfilled). I try to use a compact representation for posts, likes etc.
comment in response to
post
I just went through all the missing XRPC methods required to login or view the timeline and implemented them (or stubbed them).
Now it should be possible to use social-app on top of AppViewLite.
comment in response to
post
This is why. Most of the development effort went to the native UI, rather than XRPC endpoints and social-app compatibility.
comment in response to
post
OK then the "Fix double accounting" I just pushed should fix it
comment in response to
post
Which git commit were you running when that problem occurred?
Was it "Draining causes hangs or starvation, temporarily disable it", or something earlier?
comment in response to
post
There are currently some tracking issues, that chart can be misleading.
comment in response to
post
I archive the raw JSON responses (in addition to the compact minimal representation used internally in appviewlite), because if I need to reparse it to add more fields or make some tweaks, it's painfully slow to retrieve it from plc.directory again (the 1000-item page exports are rate limited)
comment in response to
post
So I wonder if is there's anyone at all who's successfully using jetstream with cursor, or if everyone just reconnects to realtime without cursor and accepts to lose some events
comment in response to
post
I tried both jetstream.atproto.tools (3rd party), and jetstream1.us-east.bsky.network / jetstream1.us-west.bsky.network (official).
At first I assumed it was appviewlite user code error, but then I saw other users reporting this same problem: github.com/bluesky-soci...
comment in response to
post
It has been a long time since I last worked or even used the XRPC endpoints, since most of development focus has been on the builtin UI.
Anyways adding the missing ToApiCompat() methods for converting AppViewLite native objects into XRPC objects should be fairly trivial
comment in response to
post
The set of currently active slices is controlled by a single atomically written, timestamped checkpoint file.
So if you want to load a previous checkpoint, you just have to move away the checkpoint files newer than that (AppViewLite reads the checkpoint file with the highest timestamp)