Tokens, invites and Share URLs with edit rights - no sign up / in required

[joepio]

I absolutely love saas services that provide a one-click collaboration.

Example from HackMD:

I think we could have this same feature with Atomic Data. Standardizing how this works could help to make this something that all apps could get for free - without burdening devs with implementation details.

Approaches

Query param containing scoped agent private key

This means the front-end should check the URL for a guestKey, and the server should make sure it sets the correct grants for the selected resource(s).

• Everybody with that specific URL will post things as the same agent, so it's not possible to discern multiple users.
• Server knows private key, which means it can act as if it were the guest
• No, bad idea.

Query param containing scopend token

Front-end reads query param that contains token. Front-end generates keypair, sends public key to back-end token service, which adds the newly created agent (pubkey) to the allowed posters to some scope.

In-between Invite resource

Invites are a new Class that have some fields:

• Target resource: Where the invite points to

• Usage limit: If it is a multi-use or single-use invite token?

• Target Agents: An optional set of agents that are allowed to use the Invite?

• Allows for short, query param free easy to read URLs

• Less clear what the identifier is of the actual resource being edited

When the client has fetches an Invite resource, it should know that it can post an Agent Subject (or public key?) to the Server, after which it gains the rights to edit the resource. Viewing if another question.

Multi-class resource with 'Invite' class

Atomic Data allows for multi-class resources. This means that we could have a resource with both a regular class (e.g. document) and an Invite class.

[joepio]

Sharing edit link flow

• Admin has created some Resource that they want to share edit rights to some anonymous person.
• From a UI, the Admin clicks 'create share link' on the Resource pageand selects 'edit' rights. A URL is shown and is copied to the clipboard. This URL represents an Invite Resource.
• The server has created an Invite Resource. When the User opens the Invite Resource without any query params, the Invite is shown. The front-end should then check if there is a current Agent present. If there is, a new request will be sent to the Invite with the Agent as a Query Param. Upon opening, the Server modifies the Invite, sets it to 'used', and changes the rights in the target resource accordingly.
• The User is redirected to the target resource page, and can now do anything they want.
• If the Invite URL is used later on by that same Agent, the User is redirected again.

Thoughts on implementing this

• The Browser (front-end) needs a special View for invites, which deals with setting the query param, generating the Agent key and finally the redirection to the target resource
• The Server needs to have an Extended Resource for the Invites, to deal with parsing the query param, setting the new Read / Write rights. Not sure what it should return, as Extended resources generally add some dynamic properties - which is not the case here, right? edit: maybe simply return a Redirect resource? That makes things easy!

[joepio]

When an Agent is created, should we always give the newly created Agent the rights to modify itself? I think this makes sense, as the user might want to chage their username and stuff.

[joepio]

Invites kind of need to be public (they need to be opened), but they should (most often) not be indexable. How to deal with this?

[joepio]

See https://docs.atomicdata.dev/invitations.html