NodeBB-ActivityPub Bridge Test Instance

@swaggboi @justajason religion implies dogma and rules and institution. spirituality does not.

@tedu i don't think that the AP C2S spec should be the end-all-be-all; it should be one of a suite of specs that you use. the "point" of AP is (was?) that you don't have to reimplement the delivery bits over and over, and you can use multiple clients with the same actor. just like you can use both thunderbird and claws-mail with the same email account. just like how movim lets you do pubsub against xmpp pep nodes. the cost of that 5% being copied over and over is needing 20 accounts for 20 apps.

@tedu

> How does the client get my best friends' posts?

how does a monolith get best friends' posts? it queries. vaguely something like "select * from posts where attributedTo in best_friends". the activitypub server (and linked data web in general) is your database equivalent. you would either fetch and cache data from each outbox, or you would ideally have a query endpoint with something like sparql.

> collections are untyped

this is where a schema or validation rules would be appropriate

@julian i recognize we are not there yet, but i do think we need to broadly move toward an architecture where a server going down isn’t as catastrophic as it currently is.

@julian it’s not a “must”, but it keeps data localized to where it will be used. the forum at B needs to keep at least a cached copy of P1. if A goes down, the cached copy at B still lives.

the user account at B can be logged into in potentially multiple ways; what matters for “fragmentation” is that anyone can tell when two resources are the “same”, i.e. they must be able to tell when two identities are equivalent. post P1 has url R1a and R1b and is attributed to Ua==Ub

@julian yeah, A owns the user account on A, but B might have a separate user account on B. the same logical person might control both user accounts. if identity was federated, the same credentials could be used to sign into both user accounts equally.

in other words, imagine identity server I, which is used to sign in on both A and B.

you make a post P1, which is published as R1a on A, and R1b on B. what participants need to know is that both R1a and R1b are authentic.

@hugh @skyfaller ah yeah, in a socialhub thread i called it an “impedance mismatch” and i mostly stand by that — fedi wants to do more than just sending notifications to inboxes, and reading notifications from those inboxes.

the other side of this is that the notifications themselves are often consumed as JSON-RPC instead of being kept around as bona fide resources. when’s the last time you stored a raw HTTP POST request/response message on disk? all fedi cares about is side effects…

@julian @smallcircles i think i may have said this to you before, but the precise pain point is less “i had to go to another website” and more “i can’t do anything on that other website”. the web is by design already federated in a sense, but we have built a second-layer nested/virtualized browser-within-a-browser. https://www.devever.net/~hl/webappcoupling

@julian @strypey one wonders if it would perhaps be more expedient to just do the identity bits and have the data live on B rather than ferrying it back to A.

probably what’s needed is a framework for tracking which resources are equivalent to each other. say i crosspost from my website to a forum. the post exists as two resources, one on each site, even though they are the “same” post. maybe as:alsoKnownAs can help here?

@hugh @skyfaller here, the AP server handles storage and delivery. i could then use mastodon/pixelfed/etc as clients to GET/POST against my outbox/inbox as needed, basically treating the AP server as a database of sorts, as well as a mail server of sorts.

most implementations of fedi are not like this and do not want to do this. they want to be monoliths. monoliths are “easy”. the will to abstract away social activity storage and delivery is largely not there.

@hugh @skyfaller part of the problem with how “underdefined” it is, is that we’re not talking about the big picture being there but mostly in need of filling in the gaps. we’re talking about “there is no agreed-upon authorization framework” levels of “underdefined”.

the other part is that it presupposes a wildly different topology than what fedi adheres to. the most natural interpretation of “client” is not something like Tusky. the AP client would be Mastodon itself as a client of an AP server

@tedu i don't understand this article at all. what are you supposed to ask people? the "i am going to explain to you how a conversation works" bit was especially cringe to read.

i probably need to refresh my work website in the near future as well, but if anyone has any roles related to software documentation or technical writing, then i’m available for those as well. #GetFediHired

spring 2025 financial checkin:

at present, i am very grateful for the additional runway granted to me by the contributions i have received so far. i want to thank everyone who has ever chipped in even a little bit, as it has allowed me to continue my work throughout 2024 and into 2025.

with that said, my bank account is still draining, albeit more slowly than it otherwise would be. so it’s time to pass these around again:

- https://donate.stripe.com/14kg1Og6J4jvfbW145
- https://liberapay.com/trwnh

thanks all!

had to rotate my stripe link because the old one started getting a lot of fraudulent $1 donation attempts, likely people testing stolen credit cards.

why is “cooking” good but being “cooked” bad? something doesn’t add up here

good design is invisible. that’s why all web pages should use the css rule *{display:none}

rube goldberg machines are cool and fun when you don't depend on their output in any way whatsoever

one way is to fix or reduce the horrors but the other way is to put the lid back on and never take it off again

todo investigate https://github.com/CyberShadow/aconfmgr