FEP-633c: Guardians

ActivityPub
,
1

(in case of feedback) Actor must check, if recepient ‘Guardian’ has guardians and then withhold delivery. If none of the Guardian objects of an actor are free of Guardians?
We do not GrandGuardian it (recurse). - we fail softly whispering ‘Not a Teapot’, or something.

It is a configuration error to add guardians to a profile that is Guardian

So to check, isGuardian should be an extension of the Actor object, preventing the setting of guardians. Set when the Actor is accepted as Guardian and the offer still stands.

Only Actors free of guardians are able to become Guardian.
On becoming Guardian a copy of the handle is returned for reaching said Guardian actor by said Actor, to be added to the guardians[] of the Actor that got itself a new Guardian.

An proposal is sent by the Actor offering the role of Guardian, it needs to be accepted by the recipient Actor and (whenever possible) MUST be co-accepted by (any)/another Guardian of said recipient actor.

The returning of the handle is the final okay. DO NOT ASSUME BECAUSE YOU ACCEPTED, THE OFFERING GUARDIAN WILL STILL BE OFFERING.

So, where should we start this spec?

Extending Notes, or rather any Object with the hasGuardians key, when set it indicates that the Actor responsible for this Create has Guardian actors attached in the guardians key of the Actor object.

This MUST NOT affect regular operation and can be safely ignored by non-observing implementations.

Extending Actor objects, like above: isGuardian or guardians keys are mutually exclusive.

hasGuardians on an Actor SHOULD have no effect, other than it being contentious with the isGuardian key.

-------------

On to the meat of the matter, it is all about feedback, being able to call your guardians on a post made by someone and giving your guardians a method of resolving the matter. If the post is made by an adult, adults can talk to adults, adultly address them (like flagging a missing CW, very P-A-), or entering into private conversation.

What we want to prevent? Adults screaming at kids (that have no recourse.), ‘nothing I can do’ moments, etc.

Software can:

  • Capture moderation requests to be handled differently
  • Inform Guardians of hosted Actor objects in ADDITIONAL ways
    • This means they MUST be reached by delivering a Note, AND SHOULD (for example) receive an old-school e-mail, and SMS, BOT relay .. etc.
  • Forward subscribes to (all) Guardians to co-approve
  • Forward follows to (all) Guardians to approve

What are your first thoughts, where am I missing things and can we bring this to the proper format for an acceptable released FEP?

I would love to be able to promote the fediverse as a safe alternative to #BigTech.

1 Like
2

@boiert@socialhub.activitypub.rocks I am obviously missing the removal of guardians, when is left to the guardians themselves. But the how? Removing a key from an Actor object is possible, no? Previously created objects stay in the same state (with hasGuardians), as a legacy to being young once. Of course GDPR still applies probably, or your local equivalent. So removal of all your Objects having a hasGuardians key is also possible, as some would like.

4

So removal of guardians is also a software choice.

We do have a recommendation, two actually. One would be to require at least 3 Guardians approval before removing the guardians key from an Actor. The other would be, in the case of emancipation: When the current Guardians are preventing their removal, to get at least two (2) new Guardians in there, there should be a method to allow the removal of the guardians key after a majority of previous [Guardian], and the two new Guardians consent. So, [Guardian], Guardian, Guardian need to be logical ‘ones’ in such a case, the majority of the old Guardians AND the two new Guardians.

Not expecting such a case, but counting on it to happen.

5

The draft is in submission.