search

swicg / activitypub-trust-and-safety

AP Trust and Safety Task Force repository
https://swicg.github.io/activitypub-trust-and-safety/
22 stars 0 forks source link

Taskforce Meeting 2024-11-12 #26

Open ThisIsMissEm opened 7 hours ago

ThisIsMissEm commented 7 hours ago

Mailing list notice: https://lists.w3.org/Archives/Public/public-swicg/2024Nov/0031.html

Agenda:

  1. IP Protection Note Reminder:
  2. Reminder of Code of Conduct
  3. Introductions & Overview
  4. Meeting times and cadence
    • Proposal: Every two weeks at 5pm CET on Tuesdays
  5. Defining and agreeing on Scope of Work for the Taskforce
    • Proposal: Initially work on items related to long-standing federation issues:
      • formalizing Flag activities ( #2, #3, #14, #8 )
      • discovery of moderation group actors ( #24 )
      • content warnings / labeling, as to move away from misusing summary on Note ( #1, #4 )
      • define Block activity handling / sending for S2S, currently only defined for C2S ( #23 )
      • communicating updates and conversations relating to Flag activities ( #6, #7 )
      • Explicitly out of scope, but we can include a recommendation in our report(s) about these if necessary:
      • federation management, i.e., FediBlock, since "instances" are not a thing in ActivityPub, but just a side-effect of S2S.
      • quote posts (has existing FEPs)
      • reply controls (has existing FEPs / implementations)
lisad commented 5 hours ago

I love this scope of work. Where would you slot in, if anywhere, work on sharing moderator decisions? Blocklist sharing exists in practice, does it need work for interoperability or better functionality?

evanp commented 4 hours ago

Core ActivityPub and Activity Streams 2.0 issues are not in scope for this task force. We have an existing process for working on them.

It would be a good idea to stay focused on building extension vocabularies and interfaces with other protocols.

ThisIsMissEm commented 3 hours ago

I love this scope of work. Where would you slot in, if anywhere, work on sharing moderator decisions? Blocklist sharing exists in practice, does it need work for interoperability or better functionality?

@lisad for now, I'm wanting to keep this out of scope, as just federating Block(actor) activities isn't well defined, and "instances" aren't a thing in ActivityPub, we just have Actors who happen to share the same domain. So I don't think we can do anything around this at present. If we're talking blocklists of actors, then those could just be regular Collections today, and then you'd need some way to subscribe to them and get data.

ThisIsMissEm commented 3 hours ago

Core ActivityPub and Activity Streams 2.0 issues are not in scope for this task force. We have an existing process for working on them.

It would be a good idea to stay focused on building extension vocabularies and interfaces with other protocols.

@evanp I'm not sure what you mean by this comment. Is there a specific item that you're against us working on?

evanp commented 2 hours ago

It would be a good idea to stay focused on building extension vocabularies and interfaces with other protocols.

@evanp I'm not sure what you mean by this comment. Is there a specific item that you're against us working on?

Well, I think if you work on further elaboration of the Flag activity, it would be a good idea to keep it compatible to what's already in the Activity Vocabulary.

Otherwise, I'm glad to see how many of these items are for building out new vocabularies. That's the right way to move forward! 👍🏼

evanp commented 1 hour ago

One great bit might be going through the "needs FEP" issues on ActivityPub and AS2 to see if there are any that would fit in scope and benefit from attention.

ThisIsMissEm commented 1 hour ago

It would be a good idea to stay focused on building extension vocabularies and interfaces with other protocols.

@evanp I'm not sure what you mean by this comment. Is there a specific item that you're against us working on?

Well, I think if you work on further elaboration of the Flag activity, it would be a good idea to keep it compatible to what's already in the Activity Vocabulary.

Otherwise, I'm glad to see how many of these items are for building out new vocabularies. That's the right way to move forward! 👍🏼

If you currently, today, use Flag activities per AS2, you will often find your reports not actually filed, due to specific requirements from various software. I think it's within scope of this task force to both document how Flag is currently used, write FEPs for new properties (evidence for example) and delivery semantics that we would recommend when sending Flag activities (e.g., currently they're unaddressed activities sent to the reported actor's inbox, which is almost certainly incorrect).