Needed: Ideas for private group postings (possibly via "proxyUrl"?)


#1

In Friendica we already do support public groups. We do it this way:

  • Person A is posting a public post that is directed via “to” and mentions to the group B.
  • The group is checking if person A is a follower of group B.
  • If yes, then the group is transmitting an “Announce” activity to the followers of the group B.

Additionally we do know different address forms. We can address the group via “@”, then the post is transmitted to all followers of A and to the group. But we also do know the addressing via “!”. If that is done, the post is still public, but is transmitted only to the group.

This working fine on public groups, indeed you should be able to interact with the group with nearly every AP implementation.

But: Friendica does know private groups as well. These posts are non public. This means that it isn’t possible to send some “Announce” message, since the original post can’t be public. But when it isn’t public, there is no way for the followers to fetch them.

I found the “proxyUrl” value. Possibly this can be used? But how? Or do someone knows another way?


#2

I think the spec is fairly clear on the usage of the proxyUrl endpoint. You send x-www-form-urlencoded id parameter and it returns the object. Remember to set your content-type and accept xhr headers (though a good proxy will work without accept, browsers will not send the content properly and/or the server will not be able to process the parameter correctly without the content-type).

In addition to the stated usecase in the spec of fetching resources that require authentication when the server holds your actor’s private key, there is also a privacy usecase of having a server fetch your content to not expose your home client ip.

  • One more thing I thought of about the content negotiation, if you accept text/html then that means you can still have the server do templating and you don’t necessarily have to parse the json-ld client side which would probably be a lot of work.

#3

As to the original question of private groups I’m not sure I understand the scenario clearly. Can you explain with Bob and Alice story?


#4

Isn’t my “A” Alice and my “B” Bob? What is unclear?


#5

Your A and B example talks about public but then you say But private is a problem and I don’t understand how it’s different or a problem. Or how proxyUrl is related.


#6

A private post from person A has to be transferred to the followers of group B - but A doesn’t know the followers. Group B has to distribute the post from person A to its own followers.


#7

Ok so for the case of a private announce, yes the group has to forward the whole object and not just the announce activity, even if that means it has to go fetch it first. I think this is semantically the same as the owner/author distinction in diaspora/zot/friendica without being explicit about it.


#8

But how can the receivers check the validity of the announced post?


#9

Would the originating server be able to do a variant of inbox forwarding? This sounds like the “ghost replies” problem in the original AP spec, which inbox forwarding was used to solve.

If inbox forwarding is insufficient for this use case, I’ll be curious as to why it is insufficient!


#10

The obvious way is ld sigs but I am working on a different ways since ld sigs suck so bad. Essentially it works by releasing only a signature to the interested party and the signature is a blob signature not a json or ld signature. I haven’t quite worked out the negotiation /fallback yet though.


#11

I’m not sure, what “inbox forwarding” does mean.


#12

I am referring to this section: https://www.w3.org/TR/activitypub/#inbox-forwarding


#13

When @heluecht says “B has to distribute the post from person A to it’s [person B’s] followers” and when I say “the group has to forward the whole object” we are referring to “Inbox Forwarding”. It does not solve the problem because it is part of the problem scenario already.


#14

I must still not be understanding the problem – the way I understand the problem outline, private message A from person A addressed to group B will get inbox forwarded to B’s members by the server hosting group B. Whether B also wants to send an Announce in addition is just an additional feature.

Thus, in the end state, members of group B (regardless of whether A knows them) all get:

  • The original private message of A
  • The announce from B about receiving A

But, again, this is because I don’t understand the problem (help!).


#15

@_cj The “problem” is making sure that group B isn’t altering or faking posts from remote actors.

The solution is talked about here Needed: Ideas for private group postings (possibly via "proxyUrl"?)


#16

Ok. How are implementations for current inbox forwarding of messages to followers in Mastodon, Pleroma, PixelFed, etc doing it? Same can apply here.

Also, you may be interested in the discussion here:

Where such a spoof is also a concern for remote groups later. I believe these two threads are directly related.


#17

Yes. They are. The extension I mentioned earlier actually solves this. It was designed for a project that has been on the back burner for a while but we will need it for a front burner project soon enough so now that I know there is interest I will just have to rearrange priorities and write something up. It isn’t complicated per se but I am a fan of unambiguous documentation. :grin:


#18

I would like to make it without going beyond the standard - if possible.


#19

You can’t. The basic spec does not include the capability to overcome the private data problem. The only 2 ways are ld sigs and the extension (which is far simpler) and many (most?) implementations will never implement ld sigs because they are so terrible.