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

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

【東方爆音ジャズ6】人間の消える道 / 夜雀の歌声～ Night Bird・もう歌しか聞こえない【東京アクティブNEETs】

YouTube video by Tokyo Active NEETs

youtu.be

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

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?

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

made the front page show the inbox to help me understand apub a bit more test12-instance.whey.party

I really dont want to implement my own apub instance, maybe i can steal wafrn code since it also uses ts

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)

Ron Gunk@rongunk.bsky.social · last yr.

hi chat i think i like my idea of a glue lexicon for delcaring repost/mirror across different record collections / lexicons maybe i should write more about it maybe

hell yeah

i feel like this is stupid

i like using the did:web account as the test acc because i can change the did doc without it being permanently logged in plc.directory, and also its hosted on my own pds

lesser whey@dw.whey.party · last yr.

fjcm asdasdasdasdasd

"create" sync operation of a com.example.atpub.activity.create record what a weird and roundabout system of storing activities on the PDS

initially i thought the atpub server wouldnt need write access (or auth) to the pds but i think it still does if i want to make the atpub server stateless and completely replaceable at any time without recurring backups thanks to the data being hosted on the PDS

when should an activity embed the entire object and when should it store just a dereferenceable link ? and more specifically what is the consensus / de facto standard (and for what activity / object) that needs to be followed for maximum compatibility

shouldnt pds extensions be sidecar services instead? i think the pds should enable sidecar services by providing an easy to use api key system so devs arent required to build their new features inside the pds

Ron Gunk@rongunk.bsky.social · last yr.

can we have oauth-scoped api keys to replace app passwords please

I mean theres two painful emergent problems that didnt exist before which is first from introducing general data types from atproto to apub you'd either need to restrict to a supported set or introduce extendable parsers (or schema defined appviews) and the other is the painful (two way) conversion

Ron Gunk@rongunk.bsky.social · last yr.

how about solving portable accounts on apub by first moving canon data off the non-portable actors and then use a did to point to which actor is currently canon

Aw man fresh feeds is actually getting used that means i need to actually make it good

can we have oauth-scoped api keys to replace app passwords please

i kinda want to start forking gotosocial and try out this idea

Ron Gunk@rongunk.bsky.social · last yr.

how about solving portable accounts on apub by first moving canon data off the non-portable actors and then use a did to point to which actor is currently canon

its really cool how this website is still around

happy June Month for those who experience the passage of time

how about solving portable accounts on apub by first moving canon data off the non-portable actors and then use a did to point to which actor is currently canon

i got baited into reposting a RSC blog post

⚛️📝 New on Overreacted: Progressive JSON

Progressive JSON — overreacted

Why streaming isn't enough.

overreacted.io

Ive been thinking of using multiple transport protocols to distribute the same data and while dids kinda solve the identity part i dont really know about the data part. Encapsulation breaks all native consumption and direct translation is hard. Doing both would be ideal and bridgy already does that

constellation.microcosm.blue/links?target...