Thanks for the comment.
Technical Discussion
2
Posts
2
Posters
0
Views
-
Thanks for the comment. It's something one needs to investigate / think about. Now some thoughts:
As usual it is too much to ask from W3C ActivityPub to provide a single way to do stuff.
After a bit of research: Nodebb and Sharkey currently use a
<link rel="alternate" type="application/activity+json"in their head to link to the ActivityPub representation. I personally also like it because it's easier to parse, read, write.I'm deploying a new cattle_grid version right now to see what content-type is actually used.
See also issue#60.
-
Thanks for the comment. It's something one needs to investigate / think about. Now some thoughts:
As usual it is too much to ask from W3C ActivityPub to provide a single way to do stuff.
After a bit of research: Nodebb and Sharkey currently use a
<link rel="alternate" type="application/activity+json"in their head to link to the ActivityPub representation. I personally also like it because it's easier to parse, read, write.I'm deploying a new cattle_grid version right now to see what content-type is actually used.
See also issue#60.
@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+jsonis nicer, but media type is one of the things about which specification is not ambiguous, so I always use the required one.application/activity+jsonis (or was) used by Mastodon, so of course everyone copy-pasted it into their projects.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian hopefully this demonstrates why the distinction between "is a" and "has a" matters a lot. in the group case you would need to distinguish between delivering to a group vs delivering to a group's members. currently there's a lot of ambiguity around this in 1b12 applications.
-
@julian so we have kind of a problem of data modeling, where we have actors (inbox), collections (items[*].inbox), possibly groups which could either deliver directly (inbox) or indirectly per foaf (member[*].inbox) or double-indirectly via swicg/groups task force's current proposal (members.items[*].inbox)
we could *maybe* avoid this by directly specifying which inboxes to deliver to, a la multibox (https://w3id.org/fep/0499 is one take on this), but it's unclear which if any/all are supported.
-
@julian prior art: Web Access Control differentiates subjects who are being granted authorization to access a certain resource. they have separate properties
- agent = every value is a foaf:Agent, and access is granted directly to each entity
- agentGroup = every value is a foaf:Group, and access is granted indirectly to each foaf:member
- agentClass = every value is a rdfs:Class, and access is granted according to vocabthe classes are Agent (as:Public) and AuthenticatedAgent (logged in only)
-
@julian for what it's worth, this is what i was trying to head off in the past several months of discussion, with regards to as:context *being* an as:Collection, as opposed to *having* an associated as:Collection. it's why i wrote https://w3id.org/fep/2931 to extend from https://w3id.org/fep/7888
changing the activitypub delivery algorithm would probably end up needing new properties: one that delivers directly (deliverToActor) and one that delivers to expanded items (deliverToCollection)
-
@julian in theory there shouldn't be anything wrong with saying a Collection is also something else, but activitypub's delivery algorithm will have unintended consequences if you address a Collection that has its own inbox
also Remove is defined with respect to object+target, not object+origin. yes, this is somewhat confusing because in english we remove "from" rather than remove "to", but that's far from the only slip-up. (currently AS2 also defines you Invite an Event to a Person...)
-
@julian activitypub has no concept of replies either. neither `inReplyTo`/`replies` nor `context` were specced for activitypub. these are more generally terms from the activitystreams vocabulary, and they have no side effects defined or associated with them
-
However specifically in response to your suggestion to use an Object Observer, I am not entirely sold on the concept because it feels like an unnecessary abstraction for the purposes of skirting around a limitation in the ActivityPub specification.
In your proposed structure (feel free to correct if wrong), a resolvable context would declare an observer property pointing to an Actor, who would be federating actions out on its behalf. However, it has the same technical hurdle — lack of existing implementation — than the alternative, which is to multi-type the collection into ["OrderedCollection", "Service"] or similar.
> You also mentioned Remove, how it should look in practice? Remove from what target?
No target, but origin. The collection is removed from the audience, so the audience is set in origin.
-
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.
