Privacy by circle #323

Open
opened 2023-10-16 17:11:45 +02:00 by AntoineD · 5 comments
Member

In response to a survey I launched in my French-speaking community, several people expressed a lack of this feature, apparently present on Twitter𝕏. (I only knew about Google+, but never used it)

I was given an explanation of expected behavior :

As a user
I want to be able to define a user as part of my inner circle or not
I would like to be able to set the confidentiality of my toot to "close circle".

When a toot has "close circle" confidentiality, only the user and members of the user's circle can see the toot, as well as the replies made to this toot.

For example, a user who is not in Alice's circle will not be able to see Alice's toot reserved for his circle, nor Bob's toot, which is a reply to this toot.

I don't know if this system is feasible with ActivityPub and federated?

It reminds me of the "groups" we have today /my/messaging
Except that this feature only works with members of the same instance, and therefore doesn't federate.

I see that Bonfire offers this feature, but I don't know how it is implemented on their side: https://bonfirenetworks.org/docs/boundaries/

As this is a complex feature, a preliminary discussion is required to determine whether or not it is appropriate to integrate it into iceshrimp, as well as a technical feasibility study.

_In response to a survey I launched in my French-speaking community, several people expressed a lack of this feature, apparently present on Twitter𝕏. (I only knew about Google+, but never used it)_ I was given an explanation of expected behavior : > As a user I want to be able to define a user as part of my inner circle or not I would like to be able to set the confidentiality of my toot to "close circle". > >When a toot has "close circle" confidentiality, only the user and members of the user's circle can see the toot, as well as the replies made to this toot. > >For example, a user who is not in Alice's circle will not be able to see Alice's toot reserved for his circle, nor Bob's toot, which is a reply to this toot. **I don't know if this system is feasible with ActivityPub and federated?** It reminds me of the "groups" we have today `/my/messaging` Except that this feature only works with members of the same instance, and therefore doesn't federate. I see that Bonfire offers this feature, but I don't know how it is implemented on their side: https://bonfirenetworks.org/docs/boundaries/ As this is a complex feature, a preliminary discussion is required to determine whether or not it is appropriate to integrate it into iceshrimp, as well as a technical feasibility study.
AntoineD added the
discussion
enhancement
labels 2023-10-16 17:11:45 +02:00
Owner

This isn't really possible with AP alone. You'd need all servers to cooperate. What's very much possible, though, is visibility presets for the specified visibility. Most servers will then pre-load that scope for any replies as well.

CC @erincandescent, maybe you can explain this a bit better :)

This isn't really possible with AP alone. You'd need all servers to cooperate. What's very much possible, though, is visibility presets for the specified visibility. Most servers will then pre-load that scope for any replies as well. CC @erincandescent, maybe you can explain this a bit better :)
Member

Theoretically there is support for this by creating additional (non-follower) Collections of actors

But But I think most other implementations will not support this

Theoretically there is support for this by creating additional (non-follower) `Collection`s of actors But But I think most other implementations will not support this

They will support parsing it, so it would make sense, but the replies will be out of scope (which is fine imo)

They will support parsing it, so it would make sense, but the replies will be out of scope (which is fine imo)
Author
Member

Ok, so in the first instance it might be smarter to wait for bonfire to be released...

And if their circle system federates with other bonfire, but not elsewhere, because an implementation is missing.

Should we rethink the issue to make ourselves compatible, and hope that others will follow?

(even if it means PRing the other Misskey forks to offer them support).

In any case, if I understand, apart from risking reinventing the wheel in our own corner, and competing with other implementations, it's better to wait for the time being.

is that it?

Ok, so in the first instance it might be smarter to wait for bonfire to be released... And if their circle system federates with other bonfire, but not elsewhere, because an implementation is missing. Should we rethink the issue to make ourselves compatible, and hope that others will follow? (even if it means PRing the other Misskey forks to offer them support). - In any case, if I understand, apart from risking reinventing the wheel in our own corner, and competing with other implementations, it's better to wait for the time being. is that it?

well, I already talked with the bonfire people once, they are already open for communication! but yes its prolly better to either release in parallel or wait till theirs is released :)
as else it prolly would be a iceshrimp only thing, thats wonky on other server softwares x3

well, I already talked with the bonfire people once, they are already open for communication! but yes its prolly better to either release in parallel or wait till theirs is released :) as else it prolly would be a iceshrimp only thing, thats wonky on other server softwares x3
AntoineD added this to the Fediverse Compatibility project 2023-12-18 14:24:05 +01:00
Sign in to join this conversation.
No milestone
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: iceshrimp/iceshrimp#323
No description provided.