ActivityPub seems to be mainly focused on posts, but some applications also make it possible to send direct messages, which I also want to make possible in my own application.
Unfortunately posts and direct messages have the same object type (Note).
So how do you mark a Note as a direct message?
I found this thread (Context vs conversation) where some differeneces between softwares are shown, that use the context or conversation property to mark a Note as direct message. I looked up how Mastodon marks direct messages and they use the property visibility with the value "direct".
But neither conversation nor visibility seems to be official properties of ActivtyPub or ActivityStreams objects. At least I havenât found anything about them at ActivityPub and Activity Vocabulary. Or did I miss a source?
context is an official ActivityStreams object property, but how can my application parse its value to distinguish if it is a post or a direct message?
I feared that it is not possible without extensions, because they are only interoperable if many applications use them.
And I also understood AS like it is only allowed to extend existing types. And because it is an extension of note, it should be written like aschrijver wrote. So applications that donât understand http://litepub.social/ns#ChatMessage could still parse the message.
Note: LitePub has been stalled since 2019-06-29 and is incomplete as a specification
So I am not sure if I should use an extension from an incomplete specification from a stalled project. Or should I ignore LitePubâs state, because this extension is used in healthy projects?
Mastodon does not use a visibility property in its ActivityPub representation (it uses it internally and in its client-to-server REST API). For Mastodon, a Direct Message is a message that is addressed (to) specific users and does not address (in to or cc) the public collection (https://www.w3.org/ns/activitystreams#Public), or the posterâs followers collection.
With Mastodonâs plans for encryption and the differences that exist in how messaging is handled between apps, now would be a great time to start fleshing out a FEP for the mechanism, to evolve along with this. It would be fabulous if someone of @mastodon or @pleroma would dedicate to help move that along?
This seems to be the most sensible approach.
Iâm doing this as well, looking for âPublicâ and âfollowersâ addressing, considering everything else direct message. No additional properties required.
Thanks for your clarification @Claire. I looked at the wrong place, my fault.
This seems to work in most cases, but there are some special cases where I am not sure if it works:
Replys on private posts
When Alice replies to a private post from Bob, she canât specify her followers as recipients (to), since they wonât necessarily be able to see Bobâs message (or can/should she?). So would this reply be interpreted as direct message in Mastodon? Or would it be interpreted as normal post, because it has Bobâs follower collection as recipients? Or does Mastodon look up if the Note which is replied to is a direct message?
posting on the private blog of someone else
I know this is not supported in all AP-applications, but it could cause similar problems as the above case.
Chat rooms
Depending on the answer to the first case, this wouldnât be a problem. But in chat rooms, where new users should be allowed to read old messages, the recipient of every message is the chat rooms follower collection (or at least I think this would be the right way to do it, not sure how other applications implement this). So there is a followers collection as recipient, but the note should still be interpreted as direct message.
@Claire I wonât disagree with how Mastodon determines a DM, but I believe thereâs a bug in how they determine a followers-only post; which turns many of our DMs into the wrong privacy icon on that platform.
I believe that the mere presence of a âccâ field causes what would otherwise be a DM to be displayed as followers-only on Mastodon and I believe this is a bug. Tested with a DM with an audience of 2 (plus the originator so 3 total), where one of the DM recipients is in the cc. Mastodon displays this as followers-only even though no followers collections were addressed.
Iâm also curious what folks are doing to determine that an addressed entity is in fact a followers collection. Hope youâre not basing it on the existence of âfollowersâ in the id as there is no guarantee that a server will use that pathname component. Thatâs why we ended up using the âdirectMessageâ attribute as a hint so as to avoid the requirement to fetch every object and check its type. Canât always do that on our platforms because we implement permissions and some fetches are going to be refused if you lack them.
The actor object has a followers property (at least at Example 1 ActivityPub). So one can fetch this object and check if its followers property is included in the to property of the note.
I donât know if anyone does it that way, but it would solve the problem of different naming conventions.
So one can fetch this object and check if its followers property is included
Certainly. But we can also include lists/circles/aspects and these are also addressable collections, but they arenât going to show up in your list of actor collections and these could also be restricted from casual access.
All Iâm saying is that without a hint by the sending server, determining with absolute precision that a particular activity is a direct message is an unsolvable problem. At best we can only examine the recipients and ultimately make a wild guess.
Indeed, what Iâve written here is a simplified version of what weâre doing: if the audience of a message that would otherwise be considered a DM includes actors that are not also mentioned (have a Mention entry in the tag property of the object), it will be considered as having âlimitedâ visibility (presented to the client as followers-only). This was a way to have basic support for supporting circles-like features from other software. I assume that it is what is happening there.
Weâre checking whether the collection identified by the followers attribute of the sender actor is included in the audience of the message.
I proposed doing that to disambiguate some âlimitedâ VS âdirectâ cases in Mastodon, but it didnât get any traction:
I agree with this. Wouldnât the best way be to say that a DirectMessage is a different type of object than a public post? Both are based on as:Note so the type property as an array is used to indicate that, as mentioned above.
Besides that broadly supporting type as an array as the standard indicates would be an advantage for future extensions to be built on the Fediverse, it would leave as:Note the lowest common denominator that actually represents⊠a note. Not a bag of properties that must be parsed to find out all the types it does represent.
Having DMâs be a different type would also more clearly indicate that they will have different behavior, and it will be easier to separately evolve what constitutes a Direct Message. When I didnât know how DMâs worked in Mastodon I found some things to be very unintuitive and DMâing a âhandle with careâ feature:
Mention someone in a DM adds them to the conversation (âWarning, @FedizenXYZ is a trollâ ⊠oops theyâre now DMâed that).
If someone else rigorously cleans up their DM inbox, they also clean up my Inbox while I want to archive these msgs.
I totally agree with this.
The current Mastodon solution is good for some cases, but has to be handled with care (like aschrijver wrote).
I can also add the following case to aschrijvers list:
If you reply to a message and remove the mention, it wonât be send to the recipient. (this was not intuitive for me, I thought âwhy should I mention the recipient in a 1to1 DM?â so I deleted the mention (I know Mastodon warns you about this, but other applications donât)).
So there are two solutions:
A new property for Note that marks it as DM or
A new type of object for DMs
If this solution is already used, it sounds like a good idea to make this the âoffical wayâ and write an FEP for this.
But I also see the advantages of defining a new type. Article and Note are different types with the same properties, so why not make ChatMessage a new type? The expected behavior of ChatMessages is so different from posts, that an own type would be justified.
To me a property-only approach to indicate we deal with something different, feels like bolting on all kinds of things on top of something that in nature represents a simple note, a blurb of short text. It is sort of hijacking the Note and say: this is a Microblogging post (or status, or⊠whatever app-specific names are used). There are tons more usages of notes, and it is really just a base type, a social primitive that ActivityStreams hands us to build on top of. That it has gained so much meaning in a Microblogging context (domain-specific) is mostly historical reasons.
The âAdditional Typeâ construct offered by type being an array with the base type first (to retain basic compatibility) and other types to indicate specializations makes sense to me. With it you can say: "This is a as:Note AND a forge:Comment AND a security:EncryptedMessage". Then the properties that may or may not occur in this object come from 3 clearly defined AS/AP vocabularies or extensions thereof, and you find the documentation how they work as clear specs in some well-defined locations.
The only issue I have with this being an array element of âtypeâ is that very few projects support type as an array. Iâm not even certain that more than about 1/3 of fediverse projects recognise url as an array 4-5 years on. But sure, we could do a sub-class instead of adding a boolean property. Or either, or both. Since thereâs already a large installed base using a boolean flag, weâll have to keep that for backward compatibility in any case.
I do have an issue designating these as a âChatMessageâ. Itâs just a private conversation between two (or more) people. âChatâ refers more to a visual presentation of a conversation and perhaps a protocol selector than a basic information type. If it is to be an array, âdirectMessageâ would still be the best descriptor for those of us who just want to know the intended privacy scope, and not force us to deal with any other implications of ChatMessage like STUN/TURN/ICE configuration and online presence and offline storage. But Iâm ok if you want to have type [ Note, directMessage, ChatMessage, forge:Message ] if you want to sub-class the best message handler for your requirements.
Yes indeed, that is something that is essential. Using type as array might be part of a new FEP, indicating desired way for the future and based on it we can continue to encourage all projects to migrate to it gradually, until other mechanisms can be safely deprecated.
Totally agree. Choosing a name that is semantically a best-fit is important and I think âDirectMessageâ comes way closer. Do you have a reason why you donât start it with a uppercase character? I feel starting with a capital for types as a convention (upper camel case) makes it easier to distinguish from properties with lowercase starting char (lower camel case).
