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

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.

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...)

@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)

I am not aware of any active development toward private federated 1b12 groups, but this is probably something of interest to every single one of us (myself, Rimu, Felix, Benti, etc.)