Make quote renotes work with other Fediverse software #8722
Comments
|
Quote is already implemented in Mastodon forks such as Fedibird, which can be federated with Misskey. However, Fedibird does not notify quotes. |
|
I wonder if inReplyTo can't be an array? |
|
I'm against implementing this because I think there will definitely be complaints about notifying quotes. |
The
Since quote renote is not to be used with the primary intention of throwing a remark at the original user (unless the system should inform the original user that they was quoted), the original user's Actor Object should not be put into |
According to the ActivityStreams 2.0 specification:
So on the one hand it says that it may contain multiple elements, but on the other hand |
|
In my opinion, acid-chicken's proposal is reasonable to put the quoted user as In the Mastodon issue, it was proposed to use a Mention in the |
|
FYI, Mastodon's REST API seems doesn't support multiple inReplyTo... https://docs.joinmastodon.org/entities/status/#in_reply_to_id also I think it would be good to notify as boost/renote instead of reply. (but also I think it is hard...) |
→ #2264 |
|
The way to make Misskey quotes work in other software is for the other software to support the concept of quotes. Until other software supports this, there is an option to send the activity as a Renote treatment, but it is wrong to send it as a reply. This is because a quote is not a reply. |
|
FYI Also; fedibird uses |
@syuilo How do you define the concept of quotes? I can agree a quote is not a reply -- the point I was trying to make is that replies are better than quotes in most situations because they keep the same context I think the real issue is whether Misskey quotes should send a notification or generate one in other software. There are some options I cover in mastodon/mastodon#18473 (comment)
|
In Misskey's implementation a quote is an ordinary Note that displays an embed of the quoted Note.
I think this is not acceptable because it degrades worse than the current approach of embedding a link in the I'm not sure why the current implementation seems to be completely out of the picture, seeing that it is seemingly starting to be adopted by other ActivityPub implementations (Fedibird, Pleroma, as I also laid out on the Mastodon issue). |
I don't think quoting and link previews are the same thing at all -- the point of a preview is to show a little bit of information before you click a link, but the point of a quote seems to be to have some external content embedded in your object (so that you don't have to click a link)
Because the current implementation (introducing a new
The 4 options I laid out above are not the only options, of course, but they are the ones that make sense for software other than Misskey. Additionally, choosing one of those 4 options has the inherent benefit of establishing semantics simply in the way the existing properties are already defined -- we already know and agree what Beyond the points above, it is up to Misskey as a project to determine what is the best approach to follow. It is then up to other projects to determine how they want to handle the received activities that are being generated by Misskey. If you want my personal opinion, I think all 4 options are ultimately fine, but they express different meanings. Therefore, it is important to determine what exactly a "quote" means, in order to choose the option that best fits that meaning. |
|
FYI: I thinking about new option: Create Note (like current), but also Announce original note with link to created Note; If implementation supports quote note, treat Announce as Create Note. but it makes twice notification on old Misskey servers. like: [{
"type": "Announce",
"id": "https://misskey.example/notes/bbbbb/activity/announce",
"_misskey_note": "https://misskey.example/notes/bbbbb",
"object": "https://misskey.example/notes/aaaaa",
}, {
"type": "Create",
"id": "https://misskey.example/notes/bbbbb/activity",
"object": "https://misskey.example/notes/bbbbb",
}] |
|
It should be possible to use In such a case, the Announce will generate a notification for a boost/renote, and the Create will generate a status in the timeline if the recipient is following the author |
|
but "object" property will be conflict... also I'm not sure current servers implementation is supporting multiple types. |
|
anything other than |
|
I think as a transition measure we could use option 3 of putting the note as an attachment in addition to the current fields. Then when there is enough support for that we could remove the |
|
on topic of since the fallback the payload would probably look something like this the general idea of a tag is you look for there is also the option of an alternative representation referring to the id of the object directly, which may be better since you can access properties of the original object like or even i can imagine this would work for non-Note objects, too? although that's a bit more fuzzy... |
|
In the Misskey web client, a quote goes in exactly the same place an image goes, is thus "included" and could be seen as an attachment from that perspective. The only concern with the |
|
Hmm, using {
"type": "Note",
"id": "https://misskey.example/note/bbbbb",
"content": "this has a @mention and a #hashtag but is also a quote\n\nRE: http:https://misskey.example/note/aaaaa",
"tag": [
{
"type": "Mention",
"href": "http:https://misskey.example/@mention",
"name": "@mention"
},
{
"type": "Hashtag",
"href": "http:https://misskey.example/tag/hashtag",
"name": "#hashtag"
},
{
"type": "Link",
"rel": "https://misskey-hub.net/ns#_misskey_quote",
"mediaType": "application/activity+json",
"href": "https://misskey.example/notes/aaaaa",
"name": "RE: https://misskey.example/notes/aaaaa"
}
]
} |
|
It seems I'm late to this discussion. FWIW my projects use an attachment of type application/activity+json. It is treated exactly the same as image and video attachments. In my view this is absolutely no different than adding an inline attachment for a photo or even more appropriately - an opengraph or OEmbed representation of an an external webpage. Plaintext projects render the attachments on the receiving end and add this rendering to the displayed post. HTML projects include it already and only provide the attachment for the benefit of the plaintext platforms, so they can render it appropriate to their needs/requirements (since these projects generally remove it from the HTML content). I suppose this is yet another place where every project has to support an ever increasing number of completely different ways of doing every little thing. |
|
As presented above the difference is in the semantics of Could you maybe give an example of how your representation would look for the example I gave above? |
|
I don't always make the photos or videos I attach to a post. I just refer to them in a manner that the plaintext platforms normally use to generate the img or video link which they stripped out of the rendered HTML that I already provided. Here is one example... |
|
So it seems we do agree in that it should be a |
|
Reviewing that after posting did point out a couple of minor issues in our attachment encoding, which I've been working on (notably the structural difference in image attachments between the activity and the underlying object). We also treat the issue of notification as orthagonal; so it's probably appropriate to add a mention in the tag element for the original author if your platform requires this for notifications. We currently do this in some but not all cases where we attach an existing post and didn't do so in this case. I'll need to add this to the remaining use cases for consistency. |
i do :) to clarify, i'm not sure what the semantics of "attaching" a quote is supposed to imply in zap's case. perhaps that the content is not to be marked up, but the attachment is to be shown separately? if that is indeed the case, then perhaps zap and misskey have two different concepts of what a "quote" is. although, seeing the generated html in i'm willing to have my mind changed along some practical lines, though, e.g. "attachment and tag have taken on different meanings and should be used in a different way than defined" (maybe attachment is for objects and tag is for substrings of content? but we still have the issue of the pseudo-Mention tag sometimes being necessary for notifying someone, which could be said to be purely a workaround for Mastodon's current notification behavior?) |
|
If quotes look like attachments in UI, it makes sense to use |
|
The desired graphical representation of a quote can be defined with css classses in post's content |
|
As mentioned earlier, we use attachment for inline media attachments of all forms, because plaintext microblogs remove the inline attachments from the HTML content and use the attachment property to add them back to the end. I'm thinking of one plaintext microblog in particular because this is the only way we can federate rich media content to said project , and it is a dominant force in the fediverse which steadfastly refuses to support HTML content. I don't use misskey so I do not know how it handles HTML. The content was already provided in HTML. If your platform doesn't require the use of attachment to indicate the presence of HTML that was removed from the content by your purifier, you can simply display the HTML and be done with it. But unfortunately, due to the existence of the afore-mentioned project, this means if you do support HTML content - internally your software also probably requires code to check whether or not an attachment was already referenced in the content so as not to display it twice. In any event, these are the reasons my software does what it does. Since we support HTML but also have to live with the elephant in the room, this turned out to be the most sensible way forward. Since we already use this mechanism for audio, video, and img media it made the most sense to extend this facility to inline Activity objects because conceptually they are treated exactly the same as the other media objects; the only difference being that they don't already have an existing HTML tag dedicated to them. If these were provided as an 'object' HTML tag inside the content, there would be no difference at all. I personally prefer to embed them server-side due to our platform requirements, though perhaps I should wrap them in an 'article' tag. |
|
i'm still not sure that we are "attaching" the quoted post vs "tagging" it -- content sanitizing or rewriting is not really relevant here. to me, the quoted post is being tagged in the same way that you would tag an account with a mention, or tagging an arbitrary string with a hashtag, etc. it does not require special handling in the same way an attached image or video would. it is simply a reference. the use of if i were writing an email that quoted another email, i would not attach the original email as a document or file -- this is why i don't think i can see how there would be confusion, though; the activitystreams vocabulary tries to clarify the distinction between these two in a not-very-clear way. "inclusion vs reference" is a bit vague at face value. |
|
I'm not seeing the practical advantage we would get from using |
|
That's exactly what we did (simply included it in the message content like email "forward inline" ) until this whole quoteUrl fiasco blew up and there became multiple incompatible and non-standard ways to reference (but not include) a quoted post in the activity. These are "forward as attachment". Most email clients support both - and this causes lots of confusion to end-users because they don't know why one would be better or worse. Thunderbird (which I use) offers a default Forward which is "inline". I got activities from Pleroma which were empty or just said "this is interesting" followed by nothing - because they didn't include it. They referenced it. And they used a non-standard activity element my software did not know about to attach it. Misskey used a completely different element. I don't really care what you use. I use attachment as it required no additional work. We already provided link attachments with a mediaType from the OStatus days. That's how we shared news articles and stuff. We provided an inline rendering and also attached a link to the original. So the code already existed to support this. If you want to use tags, go for it. If it just works and the content is displayed without requiring me to write platform-specific code, great. If not, I'll add the platform code and anybody can do it any way they want and we can all get on with our lives. |
well, i can't argue with that... "technically more correct" is basically my entire argument. if we're going to try to do this in a standard way that multiple projects can use, we should probably do it properly, no? i would just like to see more consistency in the overall ecosystem and less of "well someone did it this way first and now i guess everyone is doing it this way purely for compatibility with the existing software" like the "elephant in the room", so to speak. but i know it can come across as pedantic sometimes. i guess a parallel discussion here: does misskey plan to drop the and one other thing: if essentially, there are two or three things that IMO could/should be done:
i just think it's weird to attach a Link. the semantics of that don't really make sense to me (because a link is a reference). it makes the most sense to attach a Note or tag a Link -- while tagging the Note is acceptable, it is not preferred compared to tagging a Person in the ideal case. but the ideal case is kind of thrown out the window already because a certain elephant requires a Mention tag to notify someone instead of tagging the actor directly... basically if we're gonna be attaching something, just attach the original Note or w/e directly so we can fetch it and use properties like |
|
Both existing implementations are valid. Current Fedibird (Mastodon fork) Current Misskey What is the reason for adding another? |
|
Also, is there a possibility that each implementation plan will be supported by other implementations? |
While there are some similarities to email, this is the web. ActivityPub itself is built on the concept of using references for everything. We don't include multi-gigabyte videos in every one of our outbound posts, we attach links to them. |
|
Most projects don't actually attach Links to images or videos, they attach Image or Video objects. The On the other hand, Links fit in nicely with Mentions and Hashtags (which are, functionally speaking, specialized Links). |
Something more standard that doesn't require custom properties? |
I don't know what you think of as standard in the first place. |
|
If a quote that Mastodon thinks is standard is implemented, I think Misskey will implement it. |
It is added so it degrades nicely, so it would only make sense to remove it when other platforms can handle quotes in such a way to degrade nicely without it.
already discussed above, see:
See above. This is already a feature in Misskey so it would need to be handled by this as well. Also, since "quotes" are also just |
Shouldn't it be |
|
Since I actually have a life to live, I'll simply resolve this the "fediverse way". Going forward we will accept quoteUrl, quoteUri, _misskey_quote, Announce with content, inline content (our default), attach as Link, attach as Note, tag as Mention, tag as Link, and tag as Note. I'll also attempt to generate as many of these as I can without causing conflict, though some platforms may see duplicated content unless they take some measures to filter the duplication (as they are also required to do with the current dozen or so implementations of groups). Have I missed anything? We support three different transports on top of ActivityStreams and that media type only applies to ActivityPub. I suppose we could support an additional ActivityPub endpoint using an array with rel=alternate for that as well. |
See the situation macgirvin described -- we already have quoteUrl and quoteUri and _misskey_quote, none of which are "proper" in a way that is generic. Which of the three should a new implementation use in six months? All three? If so, it would be easier to just ignore quotes entirely than to support them. Standardization is about making it easier for the future.
This is an issue I see with trying to use mediaType on a Link instead of just attaching the Note directly or tagging a Link (without mediaType, just like a Mention or Hashtag, representing the
It's fine if it gets complicated. The data you are trying to describe is complicated in the nested quote case. You only need to resolve one layer and stop there. The last thing I'd like to say is that I wouldn't really mind either attaching a Note (by |
|
To try to move this discussion forward, I've created a more formal proposal and submitted it to FEP (Fediverse Enhancement Proposal) repository: https://codeberg.org/fediverse/fep/pulls/13 |
|
@silverpill this sounds like an interesting proposal. I guess I will make some experimental changes in Friendica to check the interoperability with other systems. |
|
@annando Great! I haven't tried to implement FEP-e232 myself, but will do that soon. The specification is still in a draft stage so it can be modified if we encounter any issues. |
|
@silverpill I already discovered an issue: Pleroma can't cope with it and seems to reject the post. |
|
Hi, there's another issue with quote renotes that doesn't seem to be discussed yet here, which is that Misskey quotes of an Akkoma post do not get listed under said Akkoma post's whole thread from their point of view (but vice versa, Akkoma quotes of Misskey notes do get listed under our point view). Can you look at this discussion and see if you can implement what this Akkoma developer is saying for the sake of interop between Misskey and Akkoma? https://meta.akkoma.dev/t/quote-posts-behave-inconsistently/669 Thank you |
|
A little update regarding FEP-e232. The proposal was thoroughly reviewed by the developer community and reached the FINAL status. Several projects implemented it, including Friendica and Threads (full list is in Implementations section). |
Summary
Quote-renotes are shown as a reply to the quoted note in Misskey, but users of Mastodon and Pleroma don't see the reply and don't get a notification. One of the Mastodon devs suggested that Misskey should change the activity it sends. I don't know much about this stuff, so I'll just link the post here: mastodon/mastodon#18473 (comment)
The text was updated successfully, but these errors were encountered: