NodeBB

@silverpill @eyeinthesky @thisismissem @smallcircles which is to say, as2 has an "object processing" mode (check name, summary, content, icon, image, ... and render generic display) and an "activity processing" mode (check actor, object, ... and render an activity in the stream) which coexist. the "activity processing" is underutilized in fedi, but it's the more interesting one because it lets you unify a lot of disparate models without forcing everything to be a Note (checkins, scrobbles, etc)

@silverpill @eyeinthesky @thisismissem @smallcircles the activity properties don't get used very much but they probably should be. the as:actor performs the as:Activity on the as:object to the as:target from the as:origin with the as:instrument leading to the as:result. and maybe in response to the as:inReplyTo? maybe with an as:summary? there are properties of as:Object that would fit well on most as:Activity nodes, although i think they are two distinct processing models (just closely related)

@gugurumbe @evan @cwebber @kopper @hongminhee yup, using full IRIs also has the advantage that ld-unaware processors only need to recognize 1 form instead of infinitely many.

the thing is, we have semantics imported from the content type (activity+json) which can also change. which is why i think versioning the context document is also important -- it freezes the semantics at the time of publishing, like pinning your dependencies.

without that, we might well have a simpler profile...

@kopper @evan @gugurumbe i think you can treat context identifiers as aliases. if you are already in a situation where you generally have to inject corrected contexts, then this should be doable.

@evan @gugurumbe @cwebber @kopper @hongminhee only for terms defined in AS2, though?

if the activitystreams context is missing in an application/activity+json document, then you MUST assume/inject it. this means you can't redefine "actor" to mean "actor in a movie".

otherwise, you don't have to augment the context with anything else. "https://w3id.org/security#publicKey" is a valid property name. the proposal is to not augment the normative context where possible. no parsing context if there is no context

@thisismissem @eyeinthesky @smallcircles likes contains Like activities; shares contains Announce activities; the exception is followers not containing the Follow activity (or not having a follows collection) (or not doing the better thing which is subscription management)

@eyeinthesky @thisismissem @smallcircles i would use as:result for this -- the *result* when you Accept the Like activity is to Add it to the likes collection... if you care about that level of detail. most people only care about the Like. maybe even less than that! (synthesizing a statement such as :bob :likes :this.)

@deadsuperhero @general @julian @evan concept: attaching Applications to your inbox, each of which do their own thing. right now we have effectively monolithic apps that have exactly one "internal AP client" attached to the inbox.

@tasket@infosec.exchange @julian

with http: and https: the pattern is not to use a protocol handler but to instead use a content-type handler. a different protocol forks the network, and leads to bad UX when you have custom protocol links being copied into apps that don't understand them. also you end up with multiple links for the same thing, and you have to recognize equivalences wherever there might be any.

web links have a "type" parameter for this. see firefox for example (pic 1) on SVG or PDF content

@DePemig for publishers you can think of a blog category as having its own atom feed or activitypub outbox. in my website's static site generator (hugo) i configure a taxonomy called "streams" which output to multiple formats

each rss channel item / atom feed entry / activitypub outbox activity / etc can be attributed to some author that doesn't have to be the actor you followed. this might cause some weirdness in tracking your "following", since you never followed the author themselves.

@DePemig

on the publisher side: create an actor representing the topic you think your audience wants to follow. when the actor is a Person (the most common case), the topic is "everything this person does". probably not what you want in all cases!

on the receiving side: you can store everything you receive in some storage backend and query it. this is what fedi does. "give me all posts by x with tag y" is a query on the entire local database of syndicated posts.