In order to simplify certain interactions with the client-to-server (C2S) interface, make client-side object signing easier and more predictable (allowing server-side transformations to an object before signing), and perhaps add more features for better user experience: I would recommend a new activity type known as Draft (or perhaps serialized as fep:Draft)
Essentially, the function of this would be a new activity type that’s [possibly] exclusive to the client-to-server interface, which would allow the server to:
- Assign identifiers to the enclosed activity/object (as in
@ids, from JSON-LD lingo) where appropriate - Reserve these assigned identifiers in the database
- Assign a
contextto a new top-level object, or else insert the context from a referenced object (frominReplyTo) - Perform minor linting, format conversion (Markdown/BBCode to HTML conversion) if not already performed by client, etc
- Validate activity recipients before submission (unresolvable recipients could omitted in output, signaling an error with the omitted receipients)
- Store a saved draft copy of a post that can be edited later on another client
This type of activity would not be anything transmitted to other servers, nor listed in an outbox—unless someone can justify a use-case where that would make sense that doesn’t broaden the scope too far.
When a Draft activity is sent to the C2S endpoint, it shall return a transformed copy of the drafted object, with all server-applied transformations applied (IDs assigned, context assignment, format conversion, validate addressed recipients).
Lastly, when something drafted is ready for publication/delivery:
- If the first-level contents of the previous Draft is a non-activity object (
Note,Article, etc), it may be sent to the C2S endpoint enclosed in aCreateactivity. - If the first-level contents of the previous Draft is an activity (e.g.
Update(Note)): The activity would be sent as-is to the C2S endpoint.
In both cases, the identifiers that were previously server-side assigned to the object/activity would help identify it as the same object that was previously drafted.
This would allow the server to be able to handle all cases of object transformation and ID assignment before publication, while client applications don’t have to make any assumptions (especially with client-side signing). It could also allow client-set identifiers for objects (such as for a CMS application, or for use with key-based DIDs), if supported, and being able to verify if the server permits it (if the IDs remain unchanged from what was originally sent in the Draft).
Additionally, support could be indicated by the presence of a ‘drafts’ endpoint, listed under the endpoints property of an actor object. The ‘drafts’ endpoint would simply be a collection of Draft activities (restricted to query by the owning actor only), allowing client applications to discover unpublished drafts. In the case of replies, a Note object (and others) could naturally indicate what a draft post was in reply to (per inReplyTo) making it possible to navigate right back to the conversation a post was being drafted for.
Overall, would there be any other helpful server-side transformations that could be included this, or other additions? Is this proposal sound, and worth developing into a FEP, or is too expansive/specific of scope?