dev log 002

Alright, I want to start this post with a celebration:

Many thanks to Ms Boba from FujoCoded for procuring a domain for this fanfic archive project!! (Also you 🫵 should donate to the FujoCoded Patreon or merch store !)

I'm still falling flat on my face trying to figure out Slices though. It's a platform where you can build your own AppView easily, but I feel like I'm just not understanding it even though a lot of people seem to be getting the hang of it quickly.

Here's the issues I'm having:

Currently, Slices has no native implementation for Astro ( but it doesn't seem to need it -- if you're only fetching data).

The problem is that it uses its own OAuth integration called AIP or "ATmosphere Authentication, Identity, and Permission Proxy" . I'm trying to use a different OAuth solution at the moment (essentially bug-testing it and documenting atm) and it doesn't seem like Slices allows for bringing your own OAuth client.

From the documentation itself, it looks like OAuth is required if you want to actually create, update, or delete records through the provided SDK. But you don't need the SDK, you can just interact directly through Slices' API . I need a bearer token for CRUD operations though, it seems.

Speaking of the SDK -- for whatever reason, the generated client for the SDK doesn't seem to have anything for com.atproto.repo.strongRef, which is what I need to grab different kinds of data by a combined set of unique identifiers (the commit timestamp and the record key, I think).

I could genuinely be doing something wrong here, I'm not entirely sure!

It would be nice to utilize the SDK, but maybe I need to just make direct requests to the API? I'm not sure. I might be overcomplicating things in my head in all honesty.

So... here's the other problem.

How the fuck does tagging work?!?! Oh my god how did AO3 do it!?!?

This is the current WIP. Look upon it and despair:

I'm using tagify at the moment, but I can't?? seem?? to get autosuggestion to work? Or autocomplete? I might have to do more testing, I don't know! (Or I probably just don't have actual tags to test against in the database. Oops.)

Maybe it'll help to lay out the initial idea I have to tags at the moment.

Right now, tags have these fields:

slug, because it'll need to be URL friendly so people can look for their favorite tags in a link.

label, so people can understand what the tag is actually saying.

type, which has four specific values to differentiate tags into these categories:

character, for, you know, your favorite blorbo.

relationship, to denote which ship is predominantly featured in the work.

series, where the character/relationship/work is from, since this is presumably a fanfic.

warnings, in case there's any content that a reader should be aware of.

I think this could reasonably be a good usecase for something like a labeler, which is technically supposed to be used for moderation. But I'm not sure! Maybe we can have both even!

This is a draft for now since I know tags are going to be important. Migrating tags in the database to different "schemas" will probably be a PITA in the future. At least lexicons are pretty forgiving though, so any tags set there should be fine while the shape of fanfic data gets Refined™ over time. (I should also probably make my code more neat and understandable as I'm hacking away at it.)

The current backend is entirely comprised of Astro actions that do primarily two things at the moment:

If a user consents to publishing their work to their PDS, then it'll make a request directly to user's PDS to add the work to their PDS.

It'll also add the work to the fanfic archive's database.

This might be fine (for now) but probably cause problems later down the line if I don't get a dedicated AppView or something. I think constantly making direct requests to a user's PDS will have two problems:

One, it could put a heavier load on the user's PDS and drive up costs for hosting your data. The PDS is meant to be a storage box in my mind. I'd rather treat it gently and not overwhelm it with too many requests at once.

Two, it could also put a lot of strain on the actual fanfic archive's servers. This can be seen with how many times AO3 has suffered from denial-of-service attacks and just plain getting overwhelmed by traffic.

Offloading a majority of the "expensive" operations (basically uploading, editing, or deleting works, rendering images, transforming ATProto data into something that a fanfic archive can process and vice versa, etc) to an AppView would partially solve these two problems.

I think traffic will always be an issue, but when a fanfic archive built on ATProto goes down, your data is still safe on your PDS (provided that your PDS didn't also go down at the same time by coincidence).

Theoretically speaking, this means you could still read your favorite fanfics without needing the archive. In the reverse case where if your PDS is down and the archive is up, your data is still accessible on the archive! You just wouldn't be able to log in and make more fanfics until your PDS is back up. This also means -- crazy scenario -- if both the archive and your PDS is down, an AppView could still have your fanfic data too since it also records every event that goes through it. (I think. I hope I'm not talking out of my ass.)

This kind of architecture spreads out points of failure. Your data would still be accessible, one way or another. Although it's always a good idea to keep backups on hand!

I've made some headway into setting up chapters and figuring out how the flow of adding a new work should go. I'm assuming many fanfic writers are familiar enough with AO3's interface, but I've also used Fanfiction.net (good lord what an insane thing to feel old about) and vaguely remember how that worked.

This is what I came up with:

As you can see, I, uh, I'm very clumsy with designing things.

This is what @veryroundedbird.house came up with:

It's much prettier. Thank you so much for submitting a PR! (Also you 🫵 should hire her !)

But! I've been meaning to wrap my head around importing or linking posts from other websites (like this one and BlueSky!) so writers can gather thread fics or micro fictions into something accessible -- or just publish to more platforms. I think this could unlock a lot cooler stuff in the future but I'm figuring things out as I go.

In any case, I'll probably need to rethink how the backend is structured (you can check it out on GitHub or Tangled ). And figure out the workflow of adding a new work. And I should actually use Slices as intended.

Stay hydrated, and I hope your day is well.