Shared realms is an excellent feature of Dexie cloud, but the e-mail-to-invite default behaviour isn't flexible enough for all use-cases. I've encountered two related issues:
Problem 1: If the developer is using custom auth, Dexie may not have e-mail addresses or those addresses may not be up-to-date with what the custom auth system knows.
Problem 2: Users who do not know each other well may not want to share their e-mail address, but still want to collaborate.
Current Solution: In the current system, both issues can be solved by e.g. the developer creating a backend endpoint that handles creating realms and adding users to it with whatever invitation infrastructure it wants to use. The problem with this solution is that a user can't hit that backend endpoint if the app is currently in offline mode.
I have two suggested solutions. Either or both could be implemented:
Proposed Solution 1: Add web hooks to Dexie cloud, such that Dexie calls out to an arbitrary HTTP endpoint provided by the webapp developer whenever an invite needs to be sent (this infrastructure could also be used for custom e-mails, as an alternative to sharing SMTP settings). This endpoint could receive the dexie-cloud ID and issue invitations however it sees fit. Options include forcibly adding them to the realm, sending an e-mail or SMS, or having the app developer implement solution 2 below.
Proposed Solution 2: In-app invitations
I think it's possible to make realm invitations work using just dexie-cloud sync without an external e-mail service. Here's how I imagine the flow:
Alice wants to invite Bob to a shared realm.
Bob shares some identifying information with Alice however he sees fit. It could be his e-mail address or an opaque custom auth ID, or even a username or possibly even Alice shares her profile in the public realm. Dexie-cloud places no restrictions on this information; the app gets to decide what to do with it.
Alice inputs this information into the webapp
The webapp uses whatever tools it has at its disposal to figure out what Bob's dexie-cloud user id is. For example, it may query a backend endpoint that looks bob's dexie-cloud ID up in an auth database.
The webapp creates a new realm using the current realm creation flow.
The webapp adds Bob's ID as a member to the realm with invite: true (or maybe appInvite: true or something to distinguish from e-mail based invites)
---- Sync to Dexie Cloud ----
Dexie cloud service recognizes that Bob has not accepted an invitation, so he is not added to the new realm yet.
Dexie cloud service adds some data to a new sharedInvites dexie-cloud table. This data would include roughly the same stuff that currently gets sent in an e-mail: who the inviter is, the name of the realm, etc.
---- The table syncs to Bob's browser ----
Bob's client webapp live-queries the invitations table and uses whatever UI it thinks is suitable to render an invitation to Bob.
Bob can either accept or decline the invite using whatever interactions make sense to that webapp. The accept or decline state gets stored in the invitation table
---- Sync to Dexie Cloud ----
Dexie-cloud service sees that an invitation was accepted and does the same magic it currently does when a user clicks the accept link in an invitation e-mail
Dexie-cloud service adds Bob to the realm
The realm data syncs to Bob's device using the existing flow
Possibly some knowledge about whether Bob accepted or declined the invite syncs back to Alice, or perhaps that information is better kept private.
At least proposed solution 1 could be implemented with generic data mutation web hooks:
It should be possible to register web hooks that listens to certain tables and criterias (configurable).
Whenever an object is created that fullfills the criteria, web hook is called and that backend could use REST api to perform additional tasks, including sending out invite on a channel of their choice.
The configuration could be done via CLI or Manager app.
Shared realms is an excellent feature of Dexie cloud, but the e-mail-to-invite default behaviour isn't flexible enough for all use-cases. I've encountered two related issues:
Problem 1: If the developer is using custom auth, Dexie may not have e-mail addresses or those addresses may not be up-to-date with what the custom auth system knows.
Problem 2: Users who do not know each other well may not want to share their e-mail address, but still want to collaborate.
Current Solution: In the current system, both issues can be solved by e.g. the developer creating a backend endpoint that handles creating realms and adding users to it with whatever invitation infrastructure it wants to use. The problem with this solution is that a user can't hit that backend endpoint if the app is currently in offline mode.
I have two suggested solutions. Either or both could be implemented:
Proposed Solution 1: Add web hooks to Dexie cloud, such that Dexie calls out to an arbitrary HTTP endpoint provided by the webapp developer whenever an invite needs to be sent (this infrastructure could also be used for custom e-mails, as an alternative to sharing SMTP settings). This endpoint could receive the dexie-cloud ID and issue invitations however it sees fit. Options include forcibly adding them to the realm, sending an e-mail or SMS, or having the app developer implement solution 2 below.
Proposed Solution 2: In-app invitations
I think it's possible to make realm invitations work using just dexie-cloud sync without an external e-mail service. Here's how I imagine the flow: