- UI for creating a Factory
- UI for specifying a Factory when creating resource actors
- Old way of creation doesn't work anymore, except for Factory itself
- UI indicates whether you're an admin user
- Settings allow to choose "resident" factories, i.e. ones automatically
offered to every newly verified user
Caveats:
- Factories are all-in-one, no mechanism yet for choosing actor types
- No UI/logic for auto-offering a Factory to all users of a different
instance, and signaling other instances about newly verified local
users
- No factories inserted to DB yet
- Admin user list specified in settings
- Admins can create a Factory via C2S
- Creating other actors via C2S the old way still works as well
- Factory S2S handler implementation still blank
Since collaborator live URIs were using CollabTopic*, this change breaks
existing live URIs, which means all existing delegation chains are now
broken. FYI if you're playing with your own Vervis deployment.
This was accidentally not happening until now.
If I, project A, send a start-Grant to my new parent project B, it means
that whoever has access to project B will have access to my settings as
well (for the specific operations their role allows).
Until now I've managed to avoid having to implement this piece quite
easily. The only temptation to implement it has been pseudo-client
features, which are basically just a workaround until Vervis gets a
separate client app.
But now, Person actors need to be able to automatically send
delegator-Grants when they receive a direct-Grant from a resource they
either asked to Join or got an Invite to. So, this creates a need to
track these joins and invites on the server side.
I'm not checking the exact minimal pieces necessary for
delegator-Grants. Instead, I'm starting a full implementation of the
person-side of Collab records (AKA direct-Grants), called Permit
records. This will also allow very convenient display of these Grants
and the extensions received through them, as well as UI buttons such as
accepting/rejecting a received Join or Invite.
Until now, adding a direct collaborator to a Project worked exactly like
with components: Invite or Join, then Accept, finally the direct-Grant.
I missed the fact that much like with project-component relationships,
projects (and teams) need to be able to send extension-Grants to their
direct collaborators.
So in Project's Grant handler it now:
- Recognizes the delegator-Grant coming from a new collaborator
- Sends extension-Grants, using the delegator-Grant as the capability
- When getting a new component and sending extension-Grants for it to
direct collaborators, Project uses their delegator-Grants as
capability
And in Project's Accept handler, it no longer sends extension-Grants
(because it doesn't yet have the collaborator's delegator-Grant at this
point).
NOTE, THIS TEMPORARILY BREAKS grant chains: If you create a Project and
add a Deck to it, you won't get an extension-Grant-for-the-Deck from the
Project, because the Project doesn't yet have your delegator-Grant.
The next commits will implement the Person-side of Collab records, and
will cause Person actors to automatically send the delegator-Grant,
fixing the break.
I was writing a topicLocalInvite handler when I realized how cumbersome
it's becoming, to have separate handlers for local activities. While it
allows me to pick custom specific message names and parameters (which is
why I took that approach in the first place), it causes a lot of
duplication and complexity (because I have to write the remote-activity
handlers anyway; adding local ones doesn't reduce complexity).
So this commit switches the entire system to communicate only using
AP/FF activities, including between local actors.
This patch makes Vervis temporarily unusable, because all actors' inbox POST
handlers use the new system, but the actual federation handler code hasn't been
ported. The next patches will port all the S2S activities supported so far, as
well as C2S.
