ilja:accept that it is only a best effort and make it clear that servers not implementing this are not malicious.I think there are other factors to consider here:First, the representation of a "quote post" is separate from the Quote activity, and separ...
-
ilja:
accept that it is only a best effort and make it clear that servers not implementing this are not malicious.
I think there are other factors to consider here:
First, the representation of a "quote post" is separate from the Quote activity, and separate from the QuoteAuthorization stamp. This means that the representation can actually be changed in the future without affecting the Quote/Accept(Quote) flow at all. But for now, given two softwares both understand the same representation, where software A supports the Accept flow and/or stamps, and software B does not, then a "quote post" coming from B is subject to the policies of A on how it wants to handle the authorization/validation aspect:
- A can show B's "quote post" as-is
- A can hide B's "quote post" in part, or otherwise refuse to treat it as a "quote post"
- A can fully hide or reject B's "quote post"
- (etc)
Essentially, the lack of support or awareness from B is not necessarily malicious and in some ways is not necessarily a significant problem either. What matters is what some third party observer C will do.
Which leads into the second point: the way the stamps are defined to work, they are agnostic to how they are used. The purpose of a stamp is to allow for verification or acknowledgement, in the same way that an official or authority might stamp a piece of paper, a letter, or an envelope in order to signal that it has been approved. But it's up to you whether you want to recognize the authority of that stamp. There are cases where you might not even check the stamp -- say for example that your policy allows mentioned users to quote without needing a stamp. Again, it comes down to policy.
The question then is about whether any given servers share the same policy. If they do, great! If not, then there might be social issues that arise because of that. And the difference between malice and ignorance is irrelevant to that situation. Remember when Wildebeest would leak "DMs" because they only understood "Public"? That's a more drastic example, but the general principle here is that even if some remote server is overly naive or unaware, then you still have to deal with their behavior. So yes, it's "best effort", but so is everything else on the network. Perhaps the language of the blog post can point this out more explicitly, that "can be quoted" is a function of whether the observer validates or not.
It could also be somewhat avoided in the case where two given servers do not share the same representation of "quote posts". But again, that kind of disparity in functionality is also quite normal on the network.
-
I have just discovered an important difference between the FEP-E232 specification and your implementation. Is this intentional? In E232 a link object contains these elements:
"Type": "link","mediaType": "application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\"","href": "https://server.example/objects/123","name": "RE: https://server.example/objects/123"Your example has these elements:
"type": "link","mediaType": "application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\"","href": "https://example.com/users/alice/statuses/1","rel": "https://misskey-hub.net/ns#_misskey_quote",The
namefrom E232 (although marked as "optional") is crucial for a visually nice embedding of the quote in the post. Implementations may replace the value of "name" within the content with the quoted object itself.I'm not sure about using
https://misskey-hub.net/ns#_misskey_quoteas a link relation. The original Misskey implementation of quoted posts works differently. It simply uses_misskey_quoteas a value in the note to point to the quoted element. (Although off the top of my head I think they now also usequoteUrl, which is used by other implementations.I suggest concentrating on E232 and omitting this
relparameter. If you want compatibility with other implementations that haven't implemented E232 yet, sendingquoteUrlas an additional value should be enough.heluecht:I suggest concentrating on E232 and omitting this
relparameter.FEP-e232 doesn't recommend any particular
relparameter because it is intended to support a wide variety of use cases, not just quotes. Some implementers decided to usehttps://misskey-hub.net/ns#_misskey_quoterelation type to indicate that link is actually a quote. That URI was chosen because Misskey is the first (or one of the first) Fediverse platforms to implement quote posts.I think standardizing that convention in this new proposal is a good idea.
