@maddyunderstars Your FEP has been added to the repository: https://codeberg.org/fediverse/fep/src/branch/main/fep/bebd/fep-bebd.md

@julian Private FEP-1b12 groups exist in Lemmy 1.0beta. I am already testing them, but there are still some issues with the federation (I am also working on a FEP that covers access control and user roles in FEP-1b12 groups)

@silverpill @julian @technical-discussion Thanks! Yes my own project Shoot, a discord-like, uses private 1b12 groups (or well, I'm working towards compliance?) for its private group chats and guild channels.

Invite codes in Shoot are currently used for joining guilds which at the moment are actually organisations of groups rather than groups themselves. I just wasn't up to writing a FEP for that yet if ever. That's why this FEP says you can use them to follow any actor, don't want to lock myself out.

you can find Shoot here: https://github.com/MaddyUnderStars/shoot

(this originally only tagged Julian but it didn't show up in nodebb, so I hope this repost does...)

@maddyunderstars

Some comments:

- watch out for "may" meaning "possibly" rather than "is permitted". E.g. in "Example restrictions". Ditto for "may not" meaning "might not" rather than "must not". Best not to use "may" unless capitalised so it has the meaning given in RFC2119.

- why must a Reject activity be sent for an invalid code?

- having unrestricted name formats is a recipe for disaster. The restrictions can be broad, but should exist. Otherwise guaranteed some nutcase will decide that their names will be 100,000 characters long, taken entirely from the ASCII codes below 32.

- similarly, allowing the document to contain additional properties without restricting the numbers, types and sizes of the additional properties either individually or in total, means someone will send you three million additional properties, just because they can.

- it seems that Actors can both send and receive activities modifying an InviteCode. It would be a good idea in this doco to always stipulate e.g. "sending Actor" or "receiving Actor", at least where it is not 100% clear from the context.

@kauer @technical-discussion good advice, thank you!

The examples restrictions section was marked non-normative which other FEPs seem to use to mean that the section is more commentary about the doc rather than actually specification language per the requirements RFC. I will check the wording of the rest of the document as well

Hm, I suppose a Reject doesn't need to be sent. It could be a MAY requirement instead. The idea was for user feedback: When I as a foreign server moderator want to make an invite, if my request was rejected I want to know quickly rather than on the next attempt to use the invite. But making it a MUST means I have to send some data back even if they're spamming me with invalid requests.

Good call on the name formats, it should at the least be the same restrictions as URLs due to webfinger

I might change the wording so that InviteCode extends Object from AS, because I'm pretty sure these default restrictions exist in there

@maddyunderstars@aus.social the "instrument" here should probably just be the URI to the invite code, rather than overloading webfinger with this

@thisismissem Ah you're right, I agree. I think this was an artifact of my original implementation if I remember correctly? In that, invite: webfinger lookups returned the actor directly rather than the invitecode, so it was impossible to know the invitecode ID. I'll update this FEP soon, thanks!

@maddyunderstars

Activities on InviteCodes

When an activity modifying the InviteCodes for an Actor is received, the Actor MUST ensure that the activity is being performed by an authorised Actor.

Did you mean "modifying the invites collection of an Actor"?
How to ensure that activity is being performed by an authorized actor?

To create a new InviteCode for an Actor, a standard Add activity is sent to the Actor the InviteCode is associated with.

Is there a Create(InviteCode) activity? Or invite code is supposed to be created as a side-effect of Add activity?

@technical-discussion

@silverpill @technical-discussion Thank you.

Yes it should probably read 'modifying the invites collection'.

There's a footnote on what authorised actors are, tldr it's however you decide to do it. Shoot checks if the activities actor is a member of the guild and that they have sufficient permissions (MANAGE_INVITES). Do you think I should elaborate more on this? I didn't want to be too specific, because Shoot permissions aren't super useful for the rest of fedi, and specifying some other mechanism might lock Shoot out.

It's a side effect of Add currently. Should it be the other way around? I guess Create<Note> adds to the outbox, so it would make sense.

@maddyunderstars @technical-discussion

Do you think I should elaborate more on this?

Yes. I think an example from FEP-1b12 realm will be helpful. Can actors from FEP-1b12 "moderators" collection be considered authorised actors?

There's a footnote on what authorised actors are, tldr it's however you decide to do it.

In that section, you mention "the 'invite-actor'". Does this term refer to InviteCode.attributedTo actor?

It's a side effect of Add currently. Should it be the other way around? I guess Create<Note> adds to the outbox, so it would make sense.

I would expect that an invite code is Created first, and then Added. At least when using ActivityPub API clients.

@silverpill @technical-discussion Yes, fep-1b12 moderators could be authorised actors.

Yes 'invite-actor' refers to InviteCode.attributedTo. I agree this isn't very clear...

I'll update the FEP soon with your feedback, thank you