Clouds sit lower in the sky lately
Clouds sit lower in the sky lately
Birds were out. Quiet though.
Footsteps sound different on wet pavement.
People dont stack chairs like they used to
the remaining parts are boring and nothing new, build a frontend from the inbox and like the only difference is that instead of writing to the db you write to the PDS and like woww thats lame
uh i migrated the hybrid account thing so that every apub object now lives under /at/ subdir so now every activity note and even actors are directly resolved from the PDS but im also bored this is boring none of this is exciting
I like that theyre releasing some of their old tracks in full on yt
youtu.be/odp7w-BNu8M
in my own system i think ill put the info either in the did doc or a companion record in the user repo (itll be like uhh at://{did}/com.example.atpub.declaration/self or some other static aturi)
would be nice if theres a universally recognized way of marking an account as bridged from either side so that multiple "bridge" systems can interop
bridgy support would be impossible right
like i can post twice, once here once apub if im replying to a bridgy account but the bridgy account when interacting with this hybrid account will see either side as non bridged so the interaction wont be bridged because bridgy doesnt know that its the same
no you suck
if you dont get it yet, the end goal is not just bridgy fed 2 electric boogaloo, its that so i can interact with actual apub users even though the canonical user is the atproto one. imagine to like an apub post and you had to make a com.example.atpub.activity record on the pds, gnarly right?
masotodon profile updated to reflect bsky profile
unlike here, in apub profile fields arent tied to a seperate record, it lives on the actor itself, so it feels weird to specify that app.bsky.actor.profile is the one to read the fields from
got it working, somehow the body was undefined
i dont get it why is this not working isnt it a valid follow activity
atp.tools/at:/dw.whey....
made the front page show the inbox to help me understand apub a bit more test12-instance.whey.party
I really only need the part where it builds views from received messages from the inbox, i dont need any of the communication parts i think
I really dont want to implement my own apub instance, maybe i can steal wafrn code since it also uses ts
To achieve maximum apub compat i think all records need to be mirrored to AS2 form first before it gets distributed and then linked via declaration. imo the benefits of ditching AS2 is not worth the added complexity in compability with normal apub
Eh it breaks CID which is bad. I think parsing the entirety of the mirror declaration collection shouldnt be that bad, its all just backlinks right
this way the inlined data doesnt need to change, even if you create a new mirror of the same data, the only thing that changes is the mirror declaration record. all other mirrors dont need to be edited again
maybe a link to the mirror declaration record could be inlined inside all representations of the data? by making it bidirectional itll help with finding other representations of the same data and also would make it way easier to know if a record is the canon one or the mirrored one
the point of this is so that finding notes would be easier, you dont need to parse every record that contains an inlined note. also helps with resolution between representations. though it might be annoying to parse through multiple (or all) mirror declaration records just to find one link
so like instead of the ap object be embedded inside the post, it should be like a com.example.mirror.declaration record that states that a specific app.bsky.feed.post record as the canon one and a specific com.example.atpub.object.note is a mirror of it
or something like that
i think the ap object shouldnt be inlined into another record (like app.bsky.feed.post) and i think i should use this glue lexicon system which enables multiple representations of the same data, so a com.example.atpub.object.note would be marked as mirror of app.bsky.feed.post (or vice versa)
the note URL is just a thin wrapper around a getRecord so the apub object is actually hosted on the PDS itself
test12-instance.whey.party/note/did%3Aw...
@dw.whey.party post "hello from the blue skies"
@did12wheypartywhwhaat@test12-instance.whey.party post "hello from the blue skies"
pdsls of the post record edited to include an apobject field
com.example.atpub.activity.create stored on the pds as well
hell yeah
i am fighting typescript at every step of the way and it is getting really annoying
activitypub notes being stored in the PDS
i feel like this is stupid
I almost got it working but suddenly the instance just doesnt want to resolve any identities