Implementing postingRestrictedToMods
Technical Discussion
6
Posts
3
Posters
19
Views
-
Hey pfefferle@mastodon.social nutomic@lemmy.ml, I'm looking to integrate support for
postingRestrictedToModsI see some discussion here:
It's a little specific, but even so, I'm happy to add it, since it solves some issues with cross-community content creation permission.
Is there a JSON-LD context I can add, since I am assuming that
postingRestrictedToModsis not standard? -
undefined nodebb@fosstodon.org shared this topic on
-
-
pfefferle@mastodon.social how has nobody complained about that yet? 😂
-
Its part of the part of the Lemmy context so you could include that.
Btw I didnt notice your post before because Lemmy doesnt support mention notifications in that context yet (it will be in 1.0).
-
Its part of the part of the Lemmy context so you could include that.
Btw I didnt notice your post before because Lemmy doesnt support mention notifications in that context yet (it will be in 1.0).
Thanks! I will do just that... mostly since I don't feel like hosting my own context just for this one property.
This feature is now implemented and should ship with the next minor version of NodeBB — v4.8.0.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
the type information is largely unnecessary and shouldn't factor into handling CRUD
Servers needs to know the core type / class in order to determine the "owner" of an object (actor, attributedTo, etc).
how does the server know which ids to assign and which ones not to?
The result property could be declared as special in the FEP. Servers will be required to assign IDs to embedded activities. What is a blank node identifier, id: null? Using this to indicate a need for ID is a good idea too.
I don't think side effect activities should be fragments.
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?
Why skip non-CRUD results? I think side effects shouldn't be limited to basic activities like Create/Update/Add/Remove.
-
@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.
-
I am not sure if generic server is even possible without FEP-2277 and FEP-fe34. Maybe duck typing (FEP-2277) could be replaced with hierarchical types, but that would require JSON-LD processing, and I don't want to make it mandatory.
If you're certain that a different flavor of generic server is possible, I can publish the side effects part as a separate FEP. This way we can focus on areas where we are in agreement.
-
@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.
