null = default (default to SITE_SCOPE on private sites, PUBLIC_SCOPE otherwise).
Notice can be of the following types:
LOCAL_PUBLIC = 1; - Local, ok to appear in public timeline
REMOTE = 0; - Sent from a remote service, hide from public timeline but show in local "and friends" timelines
LOCAL_NONPUBLIC = -1; - Local, but hide from public timeline
GATEWAY = -2; - From another non-OStatus service, will not appear in public views
Unless a notice is either SITE_SCOPE or PUBLIC_SCOPE, it cannot be repeated.
Replies to a notice must be under the same scope or narrower.
// For private streams
try {
$user = $actor->getUser();
// FIXME: We can't do bit comparison with == (Legacy StatusNet thing. Let's keep it for now.)
if ($user->private_stream && ($scope === Notice::PUBLIC_SCOPE || $scope === Notice::SITE_SCOPE)) {
$scope |= Notice::FOLLOWER_SCOPE;
}
Scopes in v2 notices is a 'bit map for distribution scope' where:
* 0 = everywhere (PUBLIC_SCOPE);
* 1 = this server only (SITE_SCOPE);
* 2 = addressees (ADDRESSEE_SCOPE);
* 4 = groups (GROUP_SCOPE);
* 8 = followers (FOLLOWER_SCOPE);
* 16 = messages (MESSAGE_SCOPE) (https://notabug.org/diogo/gnu-social/commit/06fb856d24bf1238c281360b6003ba4e708daa34);
* null = default (default to SITE_SCOPE on private sites, PUBLIC_SCOPE otherwise).
Notice can be of the following types:
* LOCAL_PUBLIC = 1; - Local, ok to appear in public timeline
* REMOTE = 0; - Sent from a remote service, hide from public timeline but show in local "and friends" timelines
* LOCAL_NONPUBLIC = -1; - Local, but hide from public timeline
* GATEWAY = -2; - From another non-OStatus service, will not appear in public views
Unless a notice is either SITE_SCOPE or PUBLIC_SCOPE, it cannot be repeated.
Replies to a notice must be under the same scope or narrower.
// For private streams
try {
$user = $actor->getUser();
// FIXME: We can't do bit comparison with == (Legacy StatusNet thing. Let's keep it for now.)
if ($user->private_stream && ($scope === Notice::PUBLIC_SCOPE || $scope === Notice::SITE_SCOPE)) {
$scope |= Notice::FOLLOWER_SCOPE;
}
rozzin: Oh god, "followers only" notes....
rozzin: GNU social had had "non-public notices" since before it was "GNU social".
rozzin: There were private groups, for example, and notices posted through those private groups would still be flagged as private on hosts that received them from the group.
diogo: well, I'm finding things such as the "private_stream" setting with the description: "whether to limit all notices to followers only"
diogo: I'll be honest, I don't love this kind of "best-effort-privacy". The fact that a "follower-only" note can become public because of a platform not having this functionality is a "don't promote this functionality" warning to me.
diogo: But I think our scoping system should at least try to be friendly with a request to keep the remote notes in privacy tho.
rozzin: I need to consult my notes on this...
commit 1a4cdb5e19414201d53e0a11c0a8f79c70632cdc
Author: Joshua Judson Rosen <rozzin@geekspace.com>
Date: Tue Feb 16 14:00:42 2016 -0500
profilesettings: disable half-baked privacy options that never really worked...
The only thing these are at all likely to really accomplishs
is to make naive users start thinking we're like Facebook or something,
and make them mad at us when they realise that these `privacy features'
are also broken here but broken in different ways than they'd expect
(e.g.: not outright lies, but broken in ways that don't make
any sense unless you math...).
rozzin: Yeah, not a lot of technical explanation in that comment, just philosophical allusion....
rozzin: includeals: "followers only" is also a longstanding feature, e.g. there's a checkbox; and it worked on identi.ca...
rozzin: diogo[gs]: I can clarify that my objection to `followers-only post constraints fails in unxpcted insidious ways' that I was expressing in that commit _wasn't_ FOLLOWER_SCOPE itself being unable to be enforced locally,
rozzin: diogo[gs]: it was that _ which set of profiles were or were not considered "followers"_ at any moment was not really controllable _remotely_.
In v3 we could only support collection-only (which forces the user to curate a profile-list). We would not provide a subscription-policy moderation functionality.
diogo: instead of having the follower only, maybe offer a profile list only?
diogo: If you have public posts, it doesn't sound right to block the follow/subscribe button
diogo: and followers-only is a very unspecified scope if you can't control who follows you
diogo: Having profile_list targets forces the user to select and narrow the audience
diogo: And that could make use of the collection target logic (technically allowing the followers collection)
rozzin: diogo[gs]: and part of that issue did seem to be a set of implementation bugs, e.g.: if you try to subscribe to a profile on a remote host, your entry in your _local_ subscription table is created immediately without first asking the remote host for permission; combined with the fact that feeds are only sent or not-sent on a *per host* level (and then the recipient host is tasked with figuring out which
rozzin: local *users* should receive it), this creates a situation where even though the local host can _enforce_ the scope, it can't correctly _delineate_...
rozzin: diogo[gs]: e.g. if 2 users on host A subscribe to a user on host B, one of them is accepted and the other is refused, then user@hostB sends out a followers-only post, the post goes to hostA because user2@hostA is an accepted follower on hostB; and then hostB looks and sees `OK, user1 and user2 both follow user@hostB' and gives them both the notice even though user@hostB didn't intend that.
rozzin: I don't recall "followers-only posts from remote OStatus feeds get translated to PUBLIC_SCOPE locally" being something that actually happened.
diogo: > diogo[gs]: e.g. if 2 users on host A subscribe to a user on host B, one of them is accepted and the other is refused, then user@hostB sends out a followers-only post, the post goes to hostA because user2@hostA is an accepted follower on hostB; and then hostB looks and sees `OK, user1 and user2 both follow user@hostB' and gives them both the notice even though user@hostB didn't intend that.
rozzin: This is all me speaking about OStatus of course, because that's where the `feeds are per host, not per user' thing comes in....
rozzin: The evils of premature optimization....
rozzin: I don't remember all of the specifics of how the scopes actually work, though--locally or through OStatus (which are two different cases...)
rozzin: I have pretty string philosophical reservations about federating `private' or `non-public' notices, even if it can `work' technically;
rozzin: there's a lot about total information-flow that plebes / `normal users' are just generally not equipped to think through--including the risks of rogue or delinquent administrators not just on their home site but on _every site_ that _any_ of their subscribers use ("what's an administrator, and why would I want one?" are question that real people ask..., and then they conclude "administrators sound terri
rozzin: ble, I think I'll just use systems that don't have administrators").
rozzin: diogo[gs]: I should probably mention that I think FOLLOWER_SCOPE SUBSCRIBE_POLICY_MODERATE are also technically two different, orthogonal things....
rozzin: And "remote subscribers-only scope with SUBSCRIBE_POLICY_MODERATE" really seems like it should imply some sort of end-to-end crypto..., which seems like kind of a pipe dream at this point.
rozzin: TBH..., and to be *blunt*..., I still kind of feel like *actively reenforcing* the naive worldviews, and basically lying to your users about how the network works in order to accomplish that goal, is a really shitheaded thing to do.
rozzin: And I think the optimal response to pernicious behavior like that involves calling the perpetrators out on it.
rozzin: It _doesn't_ have to involve letting those naive users get maximally punished for their mistakes, though.
diogo: I think we should try our best to respect the ideal privacy that other software ask us to; But I agree that we should maintain these functionalities only available to the extent that is more feasible (which is targets and public scope)...
rozzin: So, you know, doxxing people who made the mistake of trusting Facebook or LinkedIn or the US DoD or whomever it was who over-promised and under-delivered on users' ability to retain control over secrets that they shared with those entities... is also a lousy thing to do.
rozzin: So, I don't know--should we try to fix the bugs and keep accepting `subscribers-only' notices, or should we just reject them, or...?
rozzin: It's kind of a dilemma, because people want this stuff but don't want to think about whether they're really in an `emperor's new clothes' situation; they want to just have faith and be rewarded for that faith.
diogo: I'm mostly divided between reject and attempt to respect
diogo: Attempt to respect requires us to follow the other projects conventions and maintain a logic that we mostly won't use for our own advantage
diogo: Reject is just a matter of rejecting activities that we do not understand
We should review our privacy policy
rozzin: diogo[gs]: so..., something related: I've been thinking recently about `privacy policies', and how what I'd really like to see at some point is a privacy policy with a preamble similar in style/spirit to the GNU GPL's..., e.g.:
rozzin: > The privacy policies for most services are designed to excuse violations of your privacy. By contrast, the PINE (PINE Is Not Excuses / Policy Is No Excuse) General Privacy Policy is intended to help you protect your privacy by helping you actually understand the risks involved so that you can apply practical safeguards.
rozzin: ... and the team at jmp.chat have been working a privacy policy that is at least firmly pointed in that direction: https://jmp.chat/privacy
rozzin: diogo[gs]: and the issues we're talking about _here and now_ WRT federated social actually seem very similar in scope to what they're dealing with.
rozzin: So, to Mastodon its due credits: https://mastodon.social/terms _actually does not look so bad_, e.g.:
rozzin: > Direct and followers-only posts: All posts are stored and processed on the server. Followers-only posts are delivered to your followers and users who are mentioned in them, and direct posts are delivered only to users mentioned in them. In some cases it means they are delivered to different servers and copies are stored there. We make a good faith effort to limit the access to those posts only to auth
rozzin: orized persons, but other servers may fail to do so. Therefore it's important to review servers your followers belong to. You may toggle an option to approve and reject new followers manually in the settings. Please keep in mind that the operators of the server and any receiving server may view such messages, and that recipients may screenshot, copy or otherwise re-share them. Do not share any dangerous
rozzin: information over Mastodon.
rozzin: diogo[gs]: we really should review our own stuff--e.g. what sort of things we say in our docs, what sort of things we _imply_ in our docs... and the extent to which our onboarding processes try to get new users to read those docs at all.
rozzin: "Write a terms of service and privacy policy" <https://github.com/mastodon/mastodon/issues/115> shows some of the discussions that I guess led to that Mastodon policy doc.
lnxw37d4: I don’t think of that as a security issue. It is more of a privacy issue. In any case, I do think that scope-limited posts are important, but from using them on Mastodon and Pleroma, I don’t believe anyone thought them out very well. (Which is why the term “DM” gets misused to describe SLPs with only one person in the scope, when these posts fail most people’s understanding of DMs.
What is Direct Messaging? Is it a group in the form of chat?
lnxw37d4: I honestly think real DMs across servers means end-to-end encryption. Scope limited posts with one or more specific people mentioned should be called something else and displayed in the intended recipients’ timelines like regular posts, because they are.
lnxw37d4: So, “intended recipients” is the catch. If one is going to support SLPs, then there needs to be a way to deliver those posts only to the intended recipients’ timelines, and only display them to when those recipients are logged in.
lnxw37d4: I mention this because I know of people who shared some seriously private information across Mastodon “DM”s, being oblivious to the differences between SLPs pretending to be DMs versus real DMs. I do tell people that if they don’t trust their site admin they need to move to a different site, but we still should not encourage people to send banking information across non-private channels pretending to be private.
rozzin: diogo[gs]: I'd really like to get better clarity on:
rozzin: * what the user expectations on the Mastodon side specifically are
rozzin: * whether the issue is hypothetical for him or if there are actual Mastodon users who are getting bitten by this
rozzin: * if there are, why he thinks those users have privacy expectations that seem to contradict what's in his policy doc
rozzin: Huh—"followers-only replies to public posts". That's an actual pattern of behavior for mastodon users?
aab: It is not the first time I discuss with mastodon users that the particular settings of "followers only" is... quite a distorted view on privacy, to say the least
aab: having that in mind... i guess what diogo[gs] is propossing would be fine - i think, it is a bit out of my scope :P
What does mastodon and how it translates to v2?
diogo: when I select followers-only in mastodon, this shows: "Your account is not locked. Anyone can follow you to view your follower-only posts."
rozzin: "is_local: -2"? That surprises me, but TBH I'd need to look up what any values actually mean for that.
rozzin: Is tinyint only 2 bits on some DBMS, or something?
XRevan86: rozzin: No, a byte.
rozzin: XRevan86: do you understand what numbering convention is in use there, then? I don't think I do....
XRevan86: rozzin: Nope.
rozzin: Looks like "-1" meant "blacklisted" at one point. And "gateway" meant `an abstraction over Twitter'.
XRevan86: The range is from -128 to 127
rozzin: grep through the git logs for "is_local [<>]" seems to give me no hits.
rozzin: But I can imagine why one might want to do something like "if is_local < 0 then it's not something we want to display in the public timeline"...; I'm not seeing occurrences of it actually having been used like that, though.
XRevan86: rozzin: That wouldn't be flexible.
rozzin: Maybe they're there and I'm just not using the right regex or waiting long enough for my grep to complete.
rozzin: XRevan86: yeah, well...:
commit 90b2b3f9d19196a6961fb7a115b48b2cbdf966ce
Author: Evan Prodromou <evan@controlyourself.ca>
Date: Tue Jun 16 21:37:04 2009 -0700
names for Notice is_local states
rozzin: And yes, that does mean what you hope it doesn't.
diogo: > "is_local: -2"? That surprises me, but TBH I'd need to look up what any values actually mean for that.
diogo: I had the same reaction, but I didn't invent that xb
diogo: -2 is GATEWAY
rozzin: Some of this terminology really could use a major overhaul....
## The state of followers-only functionality in v2
rozzin: Oh god, "followers only" notes....
rozzin: GNU social had had "non-public notices" since before it was "GNU social".
rozzin: There were private groups, for example, and notices posted through those private groups would still be flagged as private on hosts that received them from the group.
diogo: well, I'm finding things such as the "private_stream" setting with the description: "whether to limit all notices to followers only"
diogo: I'll be honest, I don't love this kind of "best-effort-privacy". The fact that a "follower-only" note can become public because of a platform not having this functionality is a "don't promote this functionality" warning to me.
diogo: But I think our scoping system should at least try to be friendly with a request to keep the remote notes in privacy tho.
rozzin: I need to consult my notes on this...
commit 1a4cdb5e19414201d53e0a11c0a8f79c70632cdc
Author: Joshua Judson Rosen <rozzin@geekspace.com>
Date: Tue Feb 16 14:00:42 2016 -0500
profilesettings: disable half-baked privacy options that never really worked...
The only thing these are at all likely to really accomplishs
is to make naive users start thinking we're like Facebook or something,
and make them mad at us when they realise that these `privacy features'
are also broken here but broken in different ways than they'd expect
(e.g.: not outright lies, but broken in ways that don't make
any sense unless you math...).
rozzin: Yeah, not a lot of technical explanation in that comment, just philosophical allusion....
rozzin: includeals: "followers only" is also a longstanding feature, e.g. there's a checkbox; and it worked on identi.ca...
rozzin: diogo[gs]: I can clarify that my objection to `followers-only post constraints fails in unxpcted insidious ways' that I was expressing in that commit _wasn't_ FOLLOWER_SCOPE itself being unable to be enforced locally,
rozzin: diogo[gs]: it was that _ which set of profiles were or were not considered "followers"_ at any moment was not really controllable _remotely_.
## In v3 we could only support collection-only (which forces the user to curate a profile-list). We would not provide a subscription-policy moderation functionality.
diogo: instead of having the follower only, maybe offer a profile list only?
diogo: If you have public posts, it doesn't sound right to block the follow/subscribe button
diogo: and followers-only is a very unspecified scope if you can't control who follows you
diogo: Having profile_list targets forces the user to select and narrow the audience
diogo: And that could make use of the collection target logic (technically allowing the followers collection)
rozzin: diogo[gs]: and part of that issue did seem to be a set of implementation bugs, e.g.: if you try to subscribe to a profile on a remote host, your entry in your _local_ subscription table is created immediately without first asking the remote host for permission; combined with the fact that feeds are only sent or not-sent on a *per host* level (and then the recipient host is tasked with figuring out which
rozzin: local *users* should receive it), this creates a situation where even though the local host can _enforce_ the scope, it can't correctly _delineate_...
rozzin: diogo[gs]: e.g. if 2 users on host A subscribe to a user on host B, one of them is accepted and the other is refused, then user@hostB sends out a followers-only post, the post goes to hostA because user2@hostA is an accepted follower on hostB; and then hostB looks and sees `OK, user1 and user2 both follow user@hostB' and gives them both the notice even though user@hostB didn't intend that.
rozzin: I don't recall "followers-only posts from remote OStatus feeds get translated to PUBLIC_SCOPE locally" being something that actually happened.
diogo: > diogo[gs]: e.g. if 2 users on host A subscribe to a user on host B, one of them is accepted and the other is refused, then user@hostB sends out a followers-only post, the post goes to hostA because user2@hostA is an accepted follower on hostB; and then hostB looks and sees `OK, user1 and user2 both follow user@hostB' and gives them both the notice even though user@hostB didn't intend that.
rozzin: This is all me speaking about OStatus of course, because that's where the `feeds are per host, not per user' thing comes in....
rozzin: The evils of premature optimization....
rozzin: I don't remember all of the specifics of how the scopes actually work, though--locally or through OStatus (which are two different cases...)
rozzin: I have pretty string philosophical reservations about federating `private' or `non-public' notices, even if it can `work' technically;
rozzin: there's a lot about total information-flow that plebes / `normal users' are just generally not equipped to think through--including the risks of rogue or delinquent administrators not just on their home site but on _every site_ that _any_ of their subscribers use ("what's an administrator, and why would I want one?" are question that real people ask..., and then they conclude "administrators sound terri
rozzin: ble, I think I'll just use systems that don't have administrators").
rozzin: diogo[gs]: I should probably mention that I think FOLLOWER_SCOPE SUBSCRIBE_POLICY_MODERATE are also technically two different, orthogonal things....
rozzin: And "remote subscribers-only scope with SUBSCRIBE_POLICY_MODERATE" really seems like it should imply some sort of end-to-end crypto..., which seems like kind of a pipe dream at this point.
rozzin: TBH..., and to be *blunt*..., I still kind of feel like *actively reenforcing* the naive worldviews, and basically lying to your users about how the network works in order to accomplish that goal, is a really shitheaded thing to do.
rozzin: And I think the optimal response to pernicious behavior like that involves calling the perpetrators out on it.
rozzin: It _doesn't_ have to involve letting those naive users get maximally punished for their mistakes, though.
diogo: I think we should try our best to respect the ideal privacy that other software ask us to; But I agree that we should maintain these functionalities only available to the extent that is more feasible (which is targets and public scope)...
rozzin: So, you know, doxxing people who made the mistake of trusting Facebook or LinkedIn or the US DoD or whomever it was who over-promised and under-delivered on users' ability to retain control over secrets that they shared with those entities... is also a lousy thing to do.
rozzin: So, I don't know--should we try to fix the bugs and keep accepting `subscribers-only' notices, or should we just reject them, or...?
rozzin: It's kind of a dilemma, because people want this stuff but don't want to think about whether they're really in an `emperor's new clothes' situation; they want to just have faith and be rewarded for that faith.
diogo: I'm mostly divided between reject and attempt to respect
diogo: Attempt to respect requires us to follow the other projects conventions and maintain a logic that we mostly won't use for our own advantage
diogo: Reject is just a matter of rejecting activities that we do not understand
## We should review our privacy policy
rozzin: diogo[gs]: so..., something related: I've been thinking recently about `privacy policies', and how what I'd really like to see at some point is a privacy policy with a preamble similar in style/spirit to the GNU GPL's..., e.g.:
rozzin: > The privacy policies for most services are designed to excuse violations of your privacy. By contrast, the PINE (PINE Is Not Excuses / Policy Is No Excuse) General Privacy Policy is intended to help you protect your privacy by helping you actually understand the risks involved so that you can apply practical safeguards.
rozzin: ... and the team at jmp.chat have been working a privacy policy that is at least firmly pointed in that direction: https://jmp.chat/privacy
rozzin: diogo[gs]: and the issues we're talking about _here and now_ WRT federated social actually seem very similar in scope to what they're dealing with.
rozzin: So, to Mastodon its due credits: https://mastodon.social/terms _actually does not look so bad_, e.g.:
rozzin: > Direct and followers-only posts: All posts are stored and processed on the server. Followers-only posts are delivered to your followers and users who are mentioned in them, and direct posts are delivered only to users mentioned in them. In some cases it means they are delivered to different servers and copies are stored there. We make a good faith effort to limit the access to those posts only to auth
rozzin: orized persons, but other servers may fail to do so. Therefore it's important to review servers your followers belong to. You may toggle an option to approve and reject new followers manually in the settings. Please keep in mind that the operators of the server and any receiving server may view such messages, and that recipients may screenshot, copy or otherwise re-share them. Do not share any dangerous
rozzin: information over Mastodon.
rozzin: diogo[gs]: we really should review our own stuff--e.g. what sort of things we say in our docs, what sort of things we _imply_ in our docs... and the extent to which our onboarding processes try to get new users to read those docs at all.
rozzin: "Write a terms of service and privacy policy" <https://github.com/mastodon/mastodon/issues/115> shows some of the discussions that I guess led to that Mastodon policy doc.
lnxw37d4: I don’t think of that as a security issue. It is more of a privacy issue. In any case, I do think that scope-limited posts are important, but from using them on Mastodon and Pleroma, I don’t believe anyone thought them out very well. (Which is why the term “DM” gets misused to describe SLPs with only one person in the scope, when these posts fail most people’s understanding of DMs.
## What is Direct Messaging? Is it a group in the form of chat?
lnxw37d4: I honestly think real DMs across servers means end-to-end encryption. Scope limited posts with one or more specific people mentioned should be called something else and displayed in the intended recipients’ timelines like regular posts, because they are.
lnxw37d4: So, “intended recipients” is the catch. If one is going to support SLPs, then there needs to be a way to deliver those posts only to the intended recipients’ timelines, and only display them to when those recipients are logged in.
lnxw37d4: I mention this because I know of people who shared some seriously private information across Mastodon “DM”s, being oblivious to the differences between SLPs pretending to be DMs versus real DMs. I do tell people that if they don’t trust their site admin they need to move to a different site, but we still should not encourage people to send banking information across non-private channels pretending to be private.
rozzin: diogo[gs]: I'd really like to get better clarity on:
rozzin: * what the user expectations on the Mastodon side specifically are
rozzin: * whether the issue is hypothetical for him or if there are actual Mastodon users who are getting bitten by this
rozzin: * if there are, why he thinks those users have privacy expectations that seem to contradict what's in his policy doc
rozzin: Huh—"followers-only replies to public posts". That's an actual pattern of behavior for mastodon users?
aab: It is not the first time I discuss with mastodon users that the particular settings of "followers only" is... quite a distorted view on privacy, to say the least
aab: having that in mind... i guess what diogo[gs] is propossing would be fine - i think, it is a bit out of my scope :P
## What does mastodon and how it translates to v2?
diogo: when I select followers-only in mastodon, this shows: "Your account is not locked. Anyone can follow you to view your follower-only posts."
rozzin: "is_local: -2"? That surprises me, but TBH I'd need to look up what any values actually mean for that.
rozzin: Is tinyint only 2 bits on some DBMS, or something?
XRevan86: rozzin: No, a byte.
rozzin: XRevan86: do you understand what numbering convention is in use there, then? I don't think I do....
XRevan86: rozzin: Nope.
rozzin: Looks like "-1" meant "blacklisted" at one point. And "gateway" meant `an abstraction over Twitter'.
XRevan86: The range is from -128 to 127
rozzin: grep through the git logs for "is_local [<>]" seems to give me no hits.
rozzin: But I can imagine why one might want to do something like "if is_local < 0 then it's not something we want to display in the public timeline"...; I'm not seeing occurrences of it actually having been used like that, though.
XRevan86: rozzin: That wouldn't be flexible.
rozzin: Maybe they're there and I'm just not using the right regex or waiting long enough for my grep to complete.
rozzin: XRevan86: yeah, well...:
commit 90b2b3f9d19196a6961fb7a115b48b2cbdf966ce
Author: Evan Prodromou <evan@controlyourself.ca>
Date: Tue Jun 16 21:37:04 2009 -0700
names for Notice is_local states
rozzin: And yes, that does mean what you hope it doesn't.
diogo: > "is_local: -2"? That surprises me, but TBH I'd need to look up what any values actually mean for that.
diogo: I had the same reaction, but I didn't invent that xb
diogo: -2 is GATEWAY
rozzin: Some of this terminology really could use a major overhaul....
public const PUBLIC = 1; // Can be shown everywhere (default)
public const LOCAL = 2; // Non-public and non-federated (default in private sites)
public const ADDRESSEE = 4; // Only if the actor is the author or one of the targets
public const GROUP = 8; // Only in the Group feed
public const COLLECTION = 16; // Only for the collection to see (same as addressee but not available in feeds, notifications only)
public const MESSAGE = 32; // Direct Message (same as Collection, but also with dedicated plugin)
In v3 it will be:
```php
public const PUBLIC = 1; // Can be shown everywhere (default)
public const LOCAL = 2; // Non-public and non-federated (default in private sites)
public const ADDRESSEE = 4; // Only if the actor is the author or one of the targets
public const GROUP = 8; // Only in the Group feed
public const COLLECTION = 16; // Only for the collection to see (same as addressee but not available in feeds, notifications only)
public const MESSAGE = 32; // Direct Message (same as Collection, but also with dedicated plugin)
```
Diogo Cordeiro
Scopes in v2 notices is a 'bit map for distribution scope' where:
06fb856d24);Notice can be of the following types:
Unless a notice is either SITE_SCOPE or PUBLIC_SCOPE, it cannot be repeated.
Replies to a notice must be under the same scope or narrower.
The state of followers-only functionality in v2
In v3 we could only support collection-only (which forces the user to curate a profile-list). We would not provide a subscription-policy moderation functionality.
We should review our privacy policy
What is Direct Messaging? Is it a group in the form of chat?
What does mastodon and how it translates to v2?
mastodon public scope root mention:
2021-12-07 14:11:53 LOG_DEBUG: [social.hackersatporto.com:519235.59e00315 POST /user/1/inbox.json] ActivityPub Inbox: Request contents: {
}
*************************** 93. row ***************************
profile_id: 141
conversation: 60 repeat_of: NULL object_type: http://activitystrea.ms/schema/1.0/note
v2 reply
2021-12-07 14:14:52 LOG_DEBUG: [social.hackersatporto.com:519937.7c6245ab POST /notice/new] ActivityPub Postman: Delivering {
} to https://mastodon.online/inbox
2021-12-07 14:14:52 LOG_DEBUG: [social.hackersatporto.com:519937.7c6245ab POST /notice/new] ActivityPub Postman: Delivery headers were: Array (
)
*************************** 94. row ***************************
profile_id: 1
conversation: 60 repeat_of: NULL object_type: http://activitystrea.ms/schema/1.0/note
mastodon followers only reply:
2021-12-07 14:17:33 LOG_DEBUG: [social.hackersatporto.com:519852.6b715da5 POST /user/1/inbox.json] ActivityPub Inbox: Request contents: {
}
*************************** 95. row ***************************
profile_id: 141
conversation: 60 repeat_of: NULL object_type: http://activitystrea.ms/schema/1.0/note
2021-12-07 14:17:33 LOG_DEBUG: [social.hackersatporto.com:519852.6b715da5 POST /user/1/inbox.json] ActivityPub Inbox: Request Headers: Array (
)
mastodon unlisted root mention:
2021-12-07 14:44:50 LOG_DEBUG: [social.hackersatporto.com:519937.26d51006 POST /user/1/inbox.json] ActivityPub Inbox: Request contents: {
}
*************************** 98. row ***************************
profile_id: 141
conversation: 63 repeat_of: NULL object_type: http://activitystrea.ms/schema/1.0/note
direct is translated to is_local = -2 and scope = 16
In v3 it will be:
Implemented. Key commits:
https://code.undefinedhackers.net/GNUsocial/gnu-social/commit/3e13765f62f6e4203e0d7ec344835ad12a0c2806
https://code.undefinedhackers.net/GNUsocial/gnu-social/commit/0c421116a68bb25c667a6541a3008272f1811adc
https://code.undefinedhackers.net/GNUsocial/gnu-social/commit/fec1861b804c3c96f3a59d646e6dfb0d4f28a265
https://code.undefinedhackers.net/GNUsocial/gnu-social/commit/a1d9909379cf003113ed5b7c2b59b59ffa92729d