Technical Discussion

@[email protected] mentioned in another thread that the way Hubzilla and threadiverse software handle group discussions is incompatible. It got me thinking about whether that is true. At its core both FEPs (171b and 1b12, respectively) rely on a central "distributor" node to send activities to recipients. @[email protected] did further comparisons in thr text of 171b itself: > Announce activity is used instead of Add. Conversation and related activities are synchronized between participants, but conversation backfilling mechanism is not specified. The questions here are: If threadiverse software federated out an Add in addition to Announce, would that satisfy basic synchronization (not backfill) requirements laid out by 171b? Is there any reason why Announce could not be used to facilitate private federated group discussions as well? Assuming visibility maintains scoped to addresses, I don't see any immediate reason why not...

@julian I don't know as much as I'd like about AT Lexicons. That is, not so much how they work, but what the grand idea is? I don't even understand if Bluesky imagines them being mixed and matched JSON-LD style. I think not?

@mcc @gbargoud cc'ing @gabboman who has integrated bluesky and blacksky and activitypub into one timeline/account on #WAFRN

@julian No, I get it. It's just a catastrophically bad engineering decision.

@julian It's the second link in "Hey Implementors"!

@[email protected] that sounds like a them problem not a my problem cc @[email protected]

@[email protected] oooh that's interesting. I actually commented on the former. But I am realizing now that NodeBB actually explicitly addresses quite a few people because we try to keep everybody in the loop. Responding to a topic with hundreds of posts could mean a Note object with hundreds of individual users addressed in cc. Perhaps it's wiser to not assume "addressed? generate notification.", and instead have configurable notifications based on thread/context participation.

@julian (I replied to this from Hubzilla, but it doesn't seem to have showed up, so reposting from Mastodon... sorry for the duplicate)Yes, it does.I think FEP-171b is the relevant spec; Mike Macgirvin's description of Conversation Containers might be relevant too.It's running Hubzilla, which is already listed as an implementer of FEP-f228. @[email protected] @silverpill

@js otherwise please stop follow me if you do not want help. @julian

@[email protected] (and others) reference this line from the spec re: delivery: > If a recipient is a Collection or OrderedCollection, then the server MUST dereference the collection (with the user's credentials) and discover inboxes for each item in the collection. — https://www.w3.org/TR/activitypub/#delivery Was there a specific use case/story that corresponded with this directive? The only commonly addressed collection I can think of is a followers collection, and: It's not common to address somebody else's followers collection. Even if it were, 7.1.2 specifically refers to inbox forwarding to manage delivery. So am I missing something, are there other user collections that are often addressed (and expected to be expanded), or should we remove this from the spec? cc @evan @[email protected]

@[email protected] @[email protected] well, in theory, you can have private likes and public likes. misskey and pleroma do public likes. mastodon does private likes, but then shows them publicly if anyone asks the origin site. because addressing is just a suggestion, apparently

#askfedi #peertube #makertube #spectravideo #activitypub #fediverse I've recently been trying to remote follow some accounts from my own peertube instance from https://makertube.net and https://spectra.video and at first it seems as though it's successful, but shortly after the subscription disappears.Is anyone else having this issue?

@evan said in ActivityPub API Client Reputation: > @thisismissem said in ActivityPub API Client Reputation: > > > I'm not actively working on any Mastodon features at the moment because they can't give credit where credit is due, which means it's not financially viable for me to contribute. I also just opened that ticket explaining the problem. CIMDs would fix. > > Oof. Let's hope they get around to it before the bad guys do. I'd rather we all don't learn a lesson about security the hard way. One could hope, but they weren't willing to back the huge amount of work to deprecate non-expiring access tokens, so that'll probably be exploited first, since there's quite literally millions of non-revoked access tokens out there. I tried to do the work to fix it on my own, but it's literally months of work to implement correctly with enough test coverage. Without them either paying me or promoting/acknowledging my work, I ran out of my own budget to be able fix their problems. > > You can't Flag a non-activitypub JSON document. > > I think you can, if you use the Link type. > > json > { > "@context": "https://www.w3.org/ns/activitystreams", > "type": "Flag", > "id": "https://social.example/activity/flag/1", > "actor": "https://social.example/user/3", > "object": { > "type": "Link", > "mediaType": "application/json", > "href": "https://client.dev/oauth/metadata.json" > }, > "content": "This is an example Flag activity for a CIMD document." > } > That'll flag it at this point in time, and the contents can change. And software in the fediverse is unlikely to be able to understand receiving a flag like that. > At the very least, manual moderation is important. "This app isn't allowed on this server." That depends on human judgement, CVE reports, whatever. Yeah, requires folks to actually build moderation tools for that and ensure moderating against an application revokes its access completely. Revoking access tokens doesn't prevent usage of data already harvested or whatever, but does prevent ongoing abuse

You asked this here: https://activitypub.space/topic/fd53b73d-bf92-4e81-a5ae-5a681e4aacd4/flag-activity?_=1768647932631 There has been no changes in status from what I last said, because I get almost zero time to work on AP T&S. I can probably explain Flag activities better in a call or something than quickly in text.

i'll hack around and find out

@julian should work again

@evan thanks! I would attend but unfortunately a winter storm hit and I'm at home watching three kids today

I've seen hints of backfill working really well, but hadn't seen good examples until recently. As more and more instances upgrade to the newer versions of Mastodon that support context, backfill from Mastodon instances will improve across the board. Today one of the most popular topics on my NodeBB instance was an update from the admin of The Forkiverse, a brand new up-and-coming instance. Despite following only one person from that instance, I was able to see every single reply from that instance, even from users I don't follow. Super stoked to see resolvable contexts and backfill working in the wild. Who says the Fediverse is quiet? Not me, anymore

What is so difficult about comparing a cached object with a new object when handling Update?Move and Remove are just as broad, and these are activities for manipulating collection items. I guess they work well for you because you don't use them for anything else.