NodeBB

@reiver i think the disjunction between Object and Link was actually unnecessary. https://github.com/w3c/activitystreams/issues/666

i also think there's too much emphasis on types when there really shouldn't be -- it's the *properties* that you end up using almost all of the time. pretty much the only types that actually matter are the Activity types (because you can't infer those).

@darius @pfefferle @evan i'm guessing that's a Norway

@kopper nah it's good shit. i've been meaning to compile all my thoughts on the subject but you basically did it for me with this piece

@hongminhee @silverpill ah, wait, i remember now -- the issue is that Codeberg Pages doesn't set CORS headers at all, which means javascript jsonld parsers like the one on the playground won't work.

although per https://codeberg.org/git-pages/git-pages#:~:text=CORS it seems that a _headers file might allow manually enabling CORS for the site?

@hongminhee @silverpill i intend to review my submitted feps soon-ish to do some spring housekeeping, and this is definitely one of the things i want to test. iirc last i checked there were some issues with how codeberg's pages-server handled headers, but the new git-pages server seems to handle them correctly now? which is a good sign

@hongminhee @silverpill i'm not sure what the "canonical" identifier would be for a FEP; currently there is no canonical identifier. there is the codeberg repo and there is the w3id.org purl service from 888d and there is also the newer codeberg.page site

re: 888d itself the FEP is near finalization, pending some open questions about what finalization means https://socialhub.activitypub.rocks/t/fep-888d-using-w3id-org-fep-as-a-namespace-for-extension-terms-and-for-fep-documents/3098/55

the w3id.org htaccess could be updated to point at fediverse.codeberg.page if there are less issues with that, tho

@silverpill @steve so we might need to recommend that these "side effect" activities in as:result SHOULD have fragment identifiers, to be able to refer to them later? or do we intend to never refer to them later? we could say they're transient activities so don't need to be referred to later (only processed in-order).

lastly as:result itself maybe doesn't have these semantics defined, so should a subproperty or different property be used, or do we skip non-CRUD results?

@silverpill @steve also the server's main responsibility being publishing and therefore needing to mint an identifier for the top level activity, we should ask if the server is expected to assign any inner ids as well? assigning ids changes the graph so it's not clear cut. <how does the server know *which* ids to assign and which ones not to?> is an open question (and maybe blank node identifiers are actually in practice required to avoid ambiguity?)

@silverpill @steve regarding as:result itself there are some other ideas that have come up in past years so good to discuss those in a more focused thread:

- either marking activities as the "result of" (maybe "in response to"?) another activity could update the other activity to refer to the later activities, or the "result of" property is defined as a @\reverse property of as:result
- quote stamps currently use result for the stamp itself, not a Create activity for it

@silverpill @steve the type information is largely unnecessary and shouldn't factor into handling CRUD, especially if the objects are managed by the client. the authorization/trust model for which activities are allowed to CRUD which objects is important but can be something other than fe34 (such as an explicit access control policy or authorization resource). also multiple CRUD mechanisms may be in use.

@steve @silverpill now if only AP had officially defined conformance profiles to this effect... (the "activity publishing profile" and the "notification delivery profile", to be clear)

@steve @silverpill in theory POST to outbox should publish the activity, and should trigger the delivery algorithm based on audience (which is another thing handled poorly compared to even smtp which it tried to copy...)

imo that should be part of the protocol contract, and the idea of "side effects" unfortunately muddles that. the guarantee should be built into the outbox delivery algorithm and an outbox should signal this algorithm is in effect.

@steve @silverpill it's why mastodon went with the concept of "stamps" as http resources that could be fetched to retrieve latest state (200 / 404). you no longer need a complete ordered history of activities and you don't need to calculate the current state from those activities.

subscription records would work the same way and could be extended to allow subscribing only to certain activities instead of an unfiltered everything

@steve @silverpill the other question is if this level of explicitness is useful. the answer AP spec gives is "no, just assume every server SHOULD do this".

and a tangent for follows: they are too stateful. you send Follow and Accept and someone knowing about those two might assume you are a follower now but not be aware of later removal or undoing (of either the Follow or Accept). this is broken in practice for years because Follow/Accept follow is not expressive enough

@steve @silverpill i assume the Undo would have a result that describes that? so Undo(Follow) might have a result of Remove from Follow.actor.following+Follow.object.followers in theory. for the other way around the Follow doesn't have a result but the Accept(Follow) has a result of Add to Follow.object.followers+Follow.actor.following

but i think Follow is a bad example because it really should be subscription record management instead, ideally.

@silverpill @steve so maybe instead of "generic activitypub server" the FEP should be called something like "explicitly specifying side effects with the result property". it seems to me like the references to 2277 and fe34 are not strictly necessary to the core idea and a separate FEP could bundle them together into a profile, like "a profile for using outbox activities to manage objects and collections". not sure what the best name is because naming things is the hardest

@silverpill @steve it sounds like you're describing an "AP server" whose primary functionality is not "publish activities" but rather "manage CRUD for objects and Add/Remove for collections", by taking the AP "side effects" for Create/Update/Delete/Add/Remove and and saying the outbox should also check as:result.

which is cool but should probably be disambiguated.

@silverpill @steve typically i've taken a view similar to IFTTT -- the activities describe things that happen, probably already happened. one or more listeners can do whatever they want with that information. CRUD is boring to me and i would rather do that with HTTP (POST/GET/PUT/DELETE); the more interesting activities are things like Listen (scrobbles) or Arrive (checkins) or Question (stackoverflow) or so on.

@silverpill @steve this actually raises an interesting question about "side effects" and where they live. in the AP spec it's rather muddled and i've talked before about the issue of "activities as content/notifications vs activities as procedure calls". i personally err toward having no side effects, which i think were kind of a mistake for the reason you bring up (generic servers can never be aware of extended side effects).

@benpate @silverpill

> object ids are usually defined by the server

the server would need to know your namespace/prefix, then mint ids in that namespace. if that is a dns name, then you get dns portability. if it's an https uri, then you ideally need to support relative references and redirects.

"create a collection" can happen over any CRUD method supported. if you use AP as an API then this would be a Create(object.type=Collection) then you get HTTP 201 Created with a Location header.