Reduce friction for temporary users

[krokosik]

Numerous issues have been raised, trying to address the core problem:

it is painful to ask friends (especially non-technical ones) to create accounts in your self hosted app just to split the bill

I understand the sentiment and also experience the friction of requiring my friends to do signups (and their utter reluctance to do so), but approaches proposed in issues like #667, #67, #685 are not thought out enough. Crucially, in contrast to apps like Spliiit, SplitPro is built around users having accounts and removing the email and account part, would raise several issues around scoping the permissions, edits, tracking activities etc. Linking accounts is also based on emails. The proposed solutions do not actually have a concrete plan to solve the technical limitation, stating for example:

Everyone with the link can then see balances and add expenses.

Without proposing how to actually implement that. As a cookie? That's very ephemeral, and I would actually prefer to have some sort of guest/anonymous account flow, in line with SplitPro semantics.

Current behavior

It is possible to have dummy users, by using the Add to SplitPro button after inputting an email. This actually creates a dummy account that then integrates with all the SP functionality, but the owner of said email still has to do sign up flow (with this exact email) to actually access the app.

Proposal

Emails would still be required, but no extra verification will be performed:

• login screen lists configured Auth Providers + Guest option
• the guest option requires an email account and creates/links to the dummy email only user
• on login, a screen says this is a public account with no authentication configured, so it's recommended to actually do the signup
• other group members will see the group member as unauthenticated (pre-defined profile pic, or an icon next to the username)

The signup would thus become optional to users who want a greater degree of control . This is of course a security concern so this guest option would be off by default and togglable via an env var. The guest users would also have limited access to the app, without being able to create groups, sending invite links and most buttons in the account page. They also shouldn't be able to edit group members and group options.

I welcome any feedback on this approach, especially whether that would satisfy the aforementioned calls to solve this:
@Ziesie1
@phisch33
@Quadrubo

[Ziesie1]

Thank you for picking up this topic and putting thought into a concrete proposal!

That said, I think this approach wouldn't solve my particular use case. The guest login still requires knowing the friend's email upfront, which is often the actual blocker: either I don't have their email address, or they simply aren't ready to join a group yet.

What I think is actually missing is the ability to create a placeholder member by name only — add them to a group, start recording expenses involving them, and then link that placeholder to a real account or email later, once the friend decides to join.

To be clear: I don't see the signup itself as the problem, and I'm not looking for a way to give unauthenticated users access to the app. What I need is a way to track expenses involving someone even when their email is unknown or they haven't registered yet, with the option to connect their real account retroactively.

[krokosik]

Right now, you can use a gibberish email (john@xyz.abc) suffix and have a placeholder user in this way, but indeed there is no way of linking that without changing the user's email address (for example via psql).

What realistic way do you see for account linking without an email address?

[phisch33]

I think this would be covered by something like #273 which would enable the admin to later change the assigned email from a gibberish one to the real one. However, I actually am looking for a way for unauthenticated users (or guest-authenticated) to access specific groups.

[Ziesie1]

Ok. I think this is a different need @phisch33. However, the proposal you wrote could also solve my issue.
With your proposal, I could create a guest account and share the link or not, as I see fit. At a later time, the user can join the group via the link and take over the account.

@krokosik I think this would solve my and the issue of @phisch33 :

• When adding a group member, allow creating a placeholder with a name only (no email required)
• The system generates a random, hard-to-guess token (e.g. UUID) and produces a shareable link: /join/{token}
• Anyone with the link can log in as that placeholder user — no signup, no email, no password
• The link can be shared via WhatsApp, SMS, etc.
• Other group members see the user as "unverified" (e.g. a small icon)
• Later, the placeholder can be upgraded to a real account: the user signs up normally and claims the placeholder via the link — all expenses and balances carry over, the access link is then invalidated
• If a placeholder user is removed from the group, their user record is deleted entirely — since they have no real account and no other associations, there is no reason to keep them around

Required DB changes (minimal):

model User {
  // existing fields ...
  accessToken   String?   @unique  // random token for link-based login
  isPlaceholder Boolean   @default(fa
}

That's it on the schema side. The main implementation work would be a small custom auth pathway that creates a session from a valid accessflow that merges the placeholder into a real account and clears the token.

[phisch33]

Thanks for picking this up.

I actually like the idea of having a guest account option to access the group, but I am not sure I understood exactly how your proposal works for the guest user. Would he still need to type his mail? I would like to have a way to smoothen out the process for the guest user, by not having them interact with their (probably gibberish) email. Ideally, the flow would look something like this:

• an authenticated user creates a member of a group, toggling it to be a "guest" user that does not need authentication
• the app creates a login-link for that user (maybe it could also automatically create the gibberish email as something like name12345@splitpro.example.com when the guest toggle is set)
• the user can use the login-link to directly access the group (the link would need to include some indication for the app that this is a guest user link with email abc@xyz.com and handle sign-in to that account automatically when accessing the app via the link)

This way, there would be no need for a (visible) "guest" option in the login screen, but the actual implementation still uses "authenticated" users. Ideally, this "authenticated" (not really, just technically) user could then use features such as profile pictures.
I agree with the point of this still being a possible security concern and off by default, as well as limiting what a guest account can do in terms of creating groups for example.

In a perfect world, such a guest user could then (within the guest users account settings in the app, or like originally suggested by @krokosik as a screen before accessing the group) offer an option to actually sign up, at this moment changing the email address to their real one.