zot:commentPolicy to limit who can comment on a post. What are the possible values of this field? Is it only set per post, or it can have a default value per actor?Delete{Note}?(I did see this, but it doesn’t answer any of my questions)
Wall-to-wall posts are federated like any other posts. The signatures are those of the wall owner (sender in this case). Some platforms will refuse these because neither the LD signature or HTTP signature is that of the original actor (the signing keys are unavailable to the person hosting the wall), but hear me out…
The end viewer typically has a relationship with the sender, not the actor. It doesn’t matter if the actor validates the message, because this could be a total stranger to the viewer. The only person the viewer has a trust relationship with and who needs to be validated “to them” is the sender. The sender in turn has a relationship with the actor and need to verify them before being allowed to post on their wall. So this verification does happen but is not visible to the end viewer.
Can this “chain of trust” be abused? Certainly. Anything can be abused. But the situation solves itself, because breaching the trust between the viewer and sender will break that relationship. It will also break any trust between the actor and the sender. And it is very easily discovered.
In any event, this mechanism is undergoing revision due to the work on private groups mentioned elsewhere. For group wall-to-wall posts the actor’s post is now HTML embedded into the body of a new post created by the sender. This will allow federation over any platform. I expect the regular wall-to-wall mechanism to be updated to the same mechanism in due course. There’s really no difference in trust - it’s just a different presentation which federates easier.
A detailed description of commentPolicy has been added to FEDERATION.md.
Post owners (and also site admins) can delete wall-to-wall posts. Any conversation owner can also delete any comments in their own conversation. Twitter-like platforms will probably reject the deletion. Facbook-like platforms will accept it. This is an unresolvable conflict between implementations (just like mention disparities), however it doesn’t matter because the wall owner always gets to decide what goes on their wall and the site owner always gets to decide what goes on their site. Period. If such deleted posts and comments end up visible on other software, it’s a fact of life.
I actually don’t care if developers on other platforms disagree with any of these mechanisms. As long as it is compliant with specifications (which I’ve found most projects ignore when it suits them), they can do whatever they want. It’s the fediverse way. Everything I do strives to be multi-protocol compliant, as I typically support more than one.
None of this sounds like a good idea
The first topic is no different than pasting an article about hydroxychloroquine into your stream from some rando website. We don’t know where it came from and whether that source has credibility. Whether or not we believe it or wish to continue following the sender depends on our trust in the person who sent it. The only other option is to reject any content which wasn’t signed by the original author in a manner consistent with ActivityPub signatures and not only is this technically “challenging” for any value of “content”, it kind of destroys the value of the fediverse for sharing information that originated anywhere else. ActivityPub is not the only mechanism for sharing information.
I’m willing to change the second (commentPolicy) as soon as ActivityPub provides a better mechanism which covers all these (or at least similar) use cases. We’re just warning you in advance that your comment may be discarded without looking at it (and providing the reason) and if your UI interprets these properties it will prevent you from wasting your time typing something that is going straight into the bitbucket. If it doesn’t, it’s only your own time that is wasted. We’re still going to discard it.
The third is non-negotiable. If somebody posts kiddie porn to my stream and it is copied to all my followers, I get to remove it and notify all my followers that I have removed it. Your project can keep it if it wants.
There is a slight correction to my description: we do not propagate site-admin deletions downstream. Their jursidiction over control of their site ends at the site boundary.
The established path for redistributing content with ActivityPub is Announce activities. These allow an actor to “repost” content from another while maintaining the integrity and link to the original author.
Signatures from a user other than the author mean basically nothing.
“none” was obviously hyperbole, hiding replies is a reasonable request, but I don’t think it’s been defined yet and I wouldn’t consider it “deletion”. Only the author of the content (or realistically also their site admin) can Delete it
In any event I was asked about obscure details of an implementation which I have knowledge of and which are currently un-supported by any project outside our family tree of fediverse applications. I provided them. I did not ask anybody to support them. I carefully considered that I’d be attacked and criticised harshly for trying to provide accurate documentation after it was specifically requested, but there it is. Each of these mechanisms predates ActivityPub by many years and we’ve found the ActivityPub “solutions” to similar problems are not viable - else we would have used them.
What anybody else does with their own implementation is their concern. Nothing I’ve documented here violates the integrity or security or “policies” of any other site or project. If it does, my implementation is the least of their worries.
Hi @macgirvin. You are quite right in pointing this out. Though I am not as deeply technically involved as I’d like to at this point, I must say that I highly appreciate and value insights such as yours about any possible extensions that are in use on top of core AP.
Quick judgment may be based on a “do I want this in my codebase” after spending only a fleety moment to peruse the information. That is unfortunate.
The strength of AP is in its Linked Data foundation that allows extension in any direction, for any domain, and any purpose. To promote this broader perspective and also in hopes of attracting more people with different backgrounds & expertise I’ve set up #fediversity:fediverse-futures category.
I for one hope you’ll continue to enlighten this community with your inspiring explorations of the federated application space 