This should probably be filed under Idea, but also under Denunciation. Denunciation of the "idea" that ACLs should be added to WAGN. ACLs have been known to be broken since the 1970s, or maybe even earlier. They are also intrinsically fascistic, something which is totally incompatible with the principles of Wagn. So, implement Object Capabilities instead. How to do this is complex but here are the highlights of the design of actually usable object-capabilities:

First, 4 flags on every link (not on cards), and they are NOT CRUD. Rather, they're read, write, meta-read, and meta-write. Create is a special kind of meta-write operation, and Delete is a special kind of meta-write operation. So they are not fundamental.

The canonical meta-write operation is actually override. As in "override any and all other permissions set on this link and allow me to change the permissions on it" since meta-write means "change how permissions and operations using permissions work". The canonical meta-read is of course "spy and monitor others' operations through this link or on this object".

Second, the flags can't be binary but have to be trinary. Each flag can be on, off, or absent. If absent, then the message gets to keep the flag it's already got. If on or off then the flag on the object clobbers the already existing flag on the message. If a link doesn't have any flags specified on it then obviously all its flags are ... absent. Hence we have inheritance in a transparent and elegant way.

Third, message passing. To perform an operation on an object, your message passes through a chain of object-capabilities. The server can make this chain of object-capabilities APPEAR flat but it has to exist nonetheless. It's entirely possible to make this compatible with REST by the way.

What are the benefits of this? Well, it's possible to create a structure, set all its permissions to Absent, then create three different caps TO that structure, one of which is read-only while the second is read-write, and the third has override. Something that is patently impossible with the ACL kind of "inheritance".

It's also possible to create "groups" just by creating intermediary structures that multiple users have access to. Everything is extremely elegant and obeys universal principles. There is no need for any admin to create groups, nor do you need an admin's permission for this to be done. In fact, groups are pretty much invisible to admins and to users who don't belong in the group. Which is exactly as it should be and is also impossible with ACLs.

There are lots and lots of tricks possible using this basic architecture. Why? Because this is a genuinely GENERAL architecture, and not ad hoc crap. Which incidentally is why all Tickets proposing to add ACLs to Wagn should be closed.

One simple trick is to create Gatekeeper objects that interpret "read" permission being set as "I give you nothing" and 'override' as "ah, now you have read access". What's the point? Well, imagine that someone can pass through such an object but must do it blindly. Kinda like when you have a login screen you must enter the password of your account without the login screen telling you what the password is for any username you choose. Now, REVERSE the meanings of 'read' permission so that when it's turned OFF the user can still pass THROUGH the object. It's got the same behaviour now after you flip the permission on it but it fails secure instead of failing insecure when you change the class of the object to something else. Yes that's right, a user can now create a card that's a login screen for a private area of the Wagn. Which means, the Wagn could have a hundred different mutually invisible groups in it.

This is also known as SCALING. Something that no wiki has ever been able to do successfully. Note that object capabilities alone are insufficient for scaling, but they are one of four key pillars. The others being economics, garbage collection, and democracy.