Open Membership in a Club

I'm thinking about a new plugin, Club, that would be a Roster that anyone can join. matrix

A Club works like a Roster until you fork the page that holds it. If the new home is not in the Club, the 'Join' button appears. Click-it and you are in. Simple, eh?

Anyone could found a new Club. Make a page meant to be shared and then add a new Club to it. This makes you the founder. You have the special privilege and obligation of holding the membership list for everyone else.

New members would add their site to your roster when they click 'join'. We don't normally let others write on your wiki but you invite this by founding the club. A server admin would have to install the Club plugin before anyone could even make such invitations.

What could go wrong?

The founder could disappear with the Club roster. Poof, there is no club. But anyone who had been sharing would still be connected by their Collaborative Links. We've considered a more complicated workflow that includes sedition. I'm not sure how that would work. post

What could go wrong? Without any defenses, potentially an awful lot could go wrong.

Some vandal could write a script to stuff the Club with fake members ruining it for everyone else. The founder could revert to a previous revision to clean this out and thus mitigate most of the damage. Perhaps the founder could open and close registrations or maybe add an enrollment-key to be spread through private channels. This ruins the openness but it is how cyberspace works today. The best defence might be to have lots of founders making lots of clubs, more than there are vandals.

Require some or maybe all of rate limiting, blacklists, probing joining site to test if it really is a wiki, and some out of band confirmation.

An attack could be on the founder's site. If we capped the size of a club then then we have a circuit breaker for that.

Similar to webmention, vouch, etc.

An attack on the member's attention is more subtle. This is the same as fake news on facebook. Maybe readers need a way to un-friend sites they find un-friendly. This could be an anti-neighborhood of sorts.

This is just a way to share attention. If you join my Club then you will get some attention from me and my members. That's not promising a lot.

Having a way of removing a site from the current neighborhood might be interesting. Though if that was something that could be forked it would be another potential attack.

I'd like to make the rules such that I could have a New Author's Club added as the last todo in the Field Guide to the Federation. See wiki This would be a likely attack surface for sure.

I remember an comment from some time ago, about only getting spam if you invite it. This has potential to let the spammer, bad actor, invite themselves.

I'm wondering if there is some clever little rule that tips behavior in favor of founders and members looking for ways to make a Club go right.

My original wiki, the People, Projects, and Patterns wiki, had a People Index page that makes some interesting reading even today. See wiki Of course that was launched into a kinder and gentler internet.

The Roster plugin formats sites in rows of 18, where that becomes the unit for adding new sites to your neighborhood. Rosters can also be divided into sections.

Maybe the default behavior for the Club plugin is to separate the rows into confirmed and unconfirmed members with a possible cap on unconfirmed. The Club founder would promote members to confirmed status by what ever means might be appropriate. The founder is then moderating membership on behalf of other members and all other readers too.

I wonder if rather than using a Club plugin this could be achieve with something that sites along side the wiki. A bit like invitation automation that exists around some slack rooms.

You give the invitation bot your email and fedwiki url - it then probably check that you really did initiate the invite, and them completes the process with a potential for a manual check. In the farm context, if providing hosting for club members, this could include the provision of a wiki.

Do you know how folks setup Slack membership automation? Does Slack provide this mechanism?

Don't think slack provides this, been a long time since I looked - I am thinking of projects like https://github.com/rauchg/slackin

That's pretty neat. Have to host a server to run it though. I wonder if that could be hacked to front-end a wiki farm?

Is slackin a node app? A fork might slide nicely into wiki-server.

That would be neat - if a user connects to a wiki that does not yet exist - they get a page that invites them to go though a self provisioning process - that creates a wiki site that comes already claimed for them. Would also counter the drive by wiki creation problem.

I hope to make an experimental version of Club plugin today. Site admins can then enable it with Plugmatic. I will consider some form of Moderation, some natural limit on size, and maybe blacklists specified as Rosters. This might be interesting: you can join my club unless you are a member of his club.

A community could federate management of the blacklist if they are annoyed by compulsive joiners.

It will be interesting to see how this works out. I think any blacklist itself needs to be moderated before the club owner finds themselves blacklisted.

One implementation detail, how does the client-side of the Club plugin know if the reader who is trying to join is joining from an origin that they own and have logged in? E My original suggestion was that you would fork the page to even see the join button. But random readers of that forked page shouldn't be the ones that are joining.

Could be tricky - but as club plugin would have to be installed for it to work the check could use a secure url on that is served by the server part of the plugin. So that checks that you are the site owner. So the client part of the plugin would need to recognise when it's on a forked copy of the page - site origin not the same as the home of the club?

That is probably not enough to prevent the join being spoofed - might want to have the join request save some random identifier in the plugin on the referring page. The club plugin on the club home site could then try accessing that page directly to check that the expect identifier has been set. A bit like some of the checks for site ownership that some of the Google tools use.

Maybe it doesn't use something stored on the page, but rather held with the server part of the plugin.

If there is a need to differentiate different club joining request there should be two values used, one as a key to get to the other the identifier.

All logic concentrated in Render and Join.

Save site and slug as club venue.

Render for founder from text & members as if Roster.

Render for others as if Transcluded Roster.

Offer Join button if forked for non-member.

Check origin, login, blacklist.

Server-side resolves joins vs. blacklist.

Examine Journal to resolve new from expelled members.

Fork from history should reverse recent decisions.

Loose Club properties when dragged to new page.