@silverpill
Technical Discussion
1
Posts
1
Posters
0
Views
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
At least from the point of view of NodeBB, when a topic is deleted, the Collection is de facto gone. That's why it's problematic to federate out a delete because nobody else can resolve it to find their "version" of your context.
-
I think context property should point to a collection (a dynamic view), but we can introduce a new Delete-able object that is linked to that collection. It could be an actor: https://codeberg.org/fediverse/fep/src/branch/main/fep/f06f/fep-f06f.md
You also mentioned Remove, how it should look in practice? Remove from what target?
-
@helge ActivityPub requires application/ld+json; profile="https://www.w3.org/ns/activitystreams"
https://www.w3.org/TR/activitypub/#retrieving-objects
The shorter form application/activity+json is nicer, but media type is one of the things about which specification is not ambiguous, so I always use the required one.
application/activity+json is (or was) used by Mastodon, so of course everyone copy-pasted it into their projects.
-
Thank you - I wasn't aware of Mitra supporting conversation containers and nomadic identity, happy to learn.
I have some questions about Mitra, I will ask them in a separate thread.
-
This is an extension of the discussion from Topic removal from a category/community.
In it, rimu@piefed.social shared the Lemmy federation primer which details that Delete(Object) is federated whenever a post is removed from a community.
I needed a way to communicate when a topic/context (not the top-level post) is removed from a category/audience, but is not deleted. You might ask — how is removing a context different from deleting it? In this case, a removed context still exists and is still resolvable. A context can removed from an audience in NodeBB.
Note that Lemmy and Piefed don't have a concept of an audience-less context, so if a context is removed from an audience, it would simply be deleted. No additional logic required.
Anyhow — when a topic is moved into Uncategorized (which is a catch-all bucket for... you guessed it, uncategorized content), NodeBB will federate a Remove. It looks something like this:
{ id: '#activity/remove/', type: 'Remove', actor: '', to: [], ccL [, object: '', origin: '', }This is live on activitypub.space already.
This goes hand-in-hand with topic moving, which would follow similar mechanisms, except it'd be a Move instead of a Remove.
I will likely write an FEP with technical details for both Remove and Move, and will include existing behaviours (Delete(Object)) as well.
-
The problem for us is that we actually did take advantage of the bi-directional data flow available with web sockets. However, probably > 90% of our websocket calls were simple data requests, so we dropped back to bog-standard GET and POST. Why re-invent the wheel?
It's that other half where you want to communicate events in real-time, where SSE makes sense.
-
Yeah I went the SSE route too. Nice n simple.
-
@evan this is what happens when you read the fedi at stoplights.
I'd think some kind of link to the "triggering" activity in the result.
(I'm speaking from a very old and rusty memory of AP, but)
Is a result an activity? Can it live on it's own? If not, it seems like a processor can make the assumption that object → result? Otherwise, a link to the triggering activity by id could work. But what to call that link? <shrugs>
