trwnh:It may be that we disagree, but my position is that the “end user” and the “end user experience” is not in any way required to conform to Mastodon’s expectations.I broadly agree.
-
trwnh:
It may be that we disagree, but my position is that the “end user” and the “end user experience” is not in any way required to conform to Mastodon’s expectations.
I broadly agree. However, one thing you said here struck me in particular.
At the level we’re working with here, there is no such thing as a “post” or a “status”, there is only an Object with a Link tag, and that Link may or may not have proof of consent attached.
Is this an attempt to invent a DRM equivalent for the Fediverse?
Even considering that question feels like a derail, so that might best be discussed elsewhere.
-
trwnh:
It may be that we disagree, but my position is that the “end user” and the “end user experience” is not in any way required to conform to Mastodon’s expectations.
I broadly agree. However, one thing you said here struck me in particular.
At the level we’re working with here, there is no such thing as a “post” or a “status”, there is only an Object with a Link tag, and that Link may or may not have proof of consent attached.
Is this an attempt to invent a DRM equivalent for the Fediverse?
Even considering that question feels like a derail, so that might best be discussed elsewhere.
It’s not really DRM because there’s no restriction mechanism and it isn’t about any “right” so much as it is about consent. Instead of technical protections or restrictions it’s just another signal that can be optional or required or ignored as anyone sees fit. You could do something similar with Mention nodes since they are a subclass of Link; perhaps you grant capability to signal “approved mentions” and revoke it when you block someone. Of course, for this kind of thing to be effective then your audience needs to fundamentally agree with you on policy. Say the policy is to unlink mentions and not copy a recipient if you reply to a post. This would be an implementation decision based on the same mechanism of “approved links”.
To be clear, you have three things going on here:
- The Link tag which signals a “quote post” to anyone sharing that definition. Other representations and definitions are possible.
- The Quote activity which allows you to notify someone that you quoted them. You could stop there and it would still be useful as a notification type.
- The approvedBy property and stamp mechanism which allows you to provide proof of acknowledgement. This concept of “approved links” is a progressive enhancement to a regular link.
These three things can be used independently of each other. The concerns have been separated to allow for this.
The outstanding shortcoming of using
approvedByon a Link is that most things in AS2 aren’t actually Links, they’re direct relations via the predicate and the object resource. So this wouldn’t work straightforwardly with replies for example, sinceinReplyToideally points to an object. At the very least, the ecosystem would have to support Link values forinReplyTo(or otherwise define a property likeinReplyToAuthorization. A similar problem would apply if the chosen representation of a “quote post” relied on a property like the myriad properties in use by various projects (quoteUrl, quoteUri, _misskey_quote).There’s also a tangential concern about whether this whole “put a Link in tag” thing makes sense, or if
tagis the appropriate property for this. But those are separate issues being tracked elsewhere (like the w3c/activitystreams and w3c/activitypub repos on github). It’s technically an indirection mechanism when perhaps a more direct relation might be more correct or useful (for example instead of tagging a Mention of a Person, you could just tag the Person).
