Additional parameter for User moderation across federation. (Authenticated)

[Spacedesolate]

As mentioned in guides, currently when you use getProfile(), you get "did", "name", "displayName" and "description".

Along with this, I think the protocol needs support for additional information, primarily an "authenticated" property, which a federation can set for its users as a signal to other federations for the level of confidence it has on an account.

For example, authenticated can have 3 values,

• 0 : Open signup/email not verified/temp or spam mail, or in general low level of confidence.
• 1 : Email verified/invited through code + captcha verification at registration
• 2 : Phone number (non burner) verified with the federation or DNS record for a domain registered for the account

Of course, this would be up to the federation to choose what they deem as levels 0,1,2. An app could openly mention this policy on its website for people running other federations to be aware and adjust their federation indexes accordingly.

This level of confidence parameter would allow for even more detailed moderation rules.

• Level 0 or 1 accounts will have stricter requirements through any ML spam filters (posts flagged at 40-60% probability, as opposed to 80% for level 2). This would help mostly in the "reach layer", where level 0 account (bot) mentioning crypto would be hidden by default, while level 2 might have normal reach for any crypto related tweets.
• Federations could completely ignore likes/trends from level 1 or 0 accounts on other federations. This is useful as there would be a big interest in boosting certain political opinion through so called "russian bots", or just simply buying likes for business promotions.
• In future if any app implements features such as community notes, they could restrict adding notes + voting to level 2 members, which helps fight fake news but maintains certain responsibility on users adding them.

If big part of the tweets/data can be managed reliably through rules similar to those above, manual moderation can better address any reports throughout the network locally without necessarily being reliant on shared global blocklists. Instead blocklist can be pointers to better moderation if needed, unless for predefined reasons such as piracy or CP.

I think this would be easiest way to curtail spam and bot activity from other federations without the binary options of federate or de-federate with particular instance. i.e. only federations that send spam through level 2 accounts will ever be de-federated, while others are dealt with softer weighing factor for level 0 and 1 accounts as chosen by each federation .

[snarfed]

This sounds like a job for the existing labeling data structures: https://blueskyweb.xyz/blog/4-13-2023-moderation . PDSes could publish this grade as a label on each of their accounts. They could also publish labels for individual features, eg email verified, phone verified, etc.

(Also just FYI, handles in the protocol are already a built in, DNS-verified way to attach domains to accounts: https://blueskyweb.xyz/blog/3-6-2023-domain-names-as-handles-in-bluesky )

[bnewbold]

Yep, account-level labels are a good fit for a lot of this, and those labels are already threaded through existing Lexicons. For example, when you get a feed you get all the account-level labels for all the post authors for posts in the feed. Labels can be both "positive" (vouch for an account) as well as "negative" (this account seems to be spam).

Some other signals that can be attached to an account to help with reputation signaling are:

• handle domain (eg, registered domain or sub-domain; reputation of top registered domain)
• did:plc: account creation time, history of PDS location, history of handle changes (eg, handle churn)
• did:web: domain-level reputation similar to handle domain
• PDS host and related metadata (IP range, network AS number, reverse IP, etc; larger providers or open trackers will know age of PDS instance in the network)

Things like attestation of phone or email verification are things we are thinking about, and tools we would like in the toolbox if needed. Phone (SMS) verification can get expensive at large scale, and has serious privacy/trust downsides, but could be one of several options. Having interactions and notifications gated by signals like account age ("less than 24hr old") and social graph position are also ideas floating around. All of this needs to be balanced against making it easy for new communities to rapidly on-board together and start interacting. For example an author should be able to invite an audience to join and immediately all start interacting with as little friction (verification steps) as possible.