Possible Addon?: User Accounts

[linw0724]

Hi, I saw this app while looking for an alternative to Splitwise and it is great! Thanks for all the time and work everyone has put in to this. I just started learning how to code as a hobby so I apologize in advance for not being able to contribute much to the project yet.

I was wondering if it would be within the ethos of the app to have user logins (at least for self hosted instances as an option) through local credentials, or through Google Auth, Facebook, etc.

My thoughts on advantages of this:

• If people create accounts on the app, it would be easier to automatically share expense groups by adding people via their accounts to a group (or if they don't have an account yet, sending a link to invite to the app).
• Once people are added to a group via their account, whenever they log in, the group they are in will be automatically shown (making group link sharing optional instead of required).
• Maybe this could also lead to Venmo/Paypal/etc integrations since there will be accounts to save user data to (if someone added payment info to their profile). Like next to the "Mark as Paid" have a "Pay Up" button that sends you to the Venmo/Paypal dialogue of the user you need to pay with the amount already inserted. I was thinking of staying with external payment services to avoid having to deal with the data security of storing actual banking information on the app instance.
• I think this could also be a way to work the Make IDs Integers #36 issue as mentioned

[bereket42]

I wonder if the core contributors are interested in allowing user accounts. If so I'd be happy to help out

[ChristopherJohnston]

for self-hosted, the easiest way to have this behind a login screen is to throw it behind an OIDC screen in a reverse proxy (such as Nginx or traefik). Apps like Keycloak, authentik or zitadel allow the management of accounts, auth and OIDC applications.

If we wanted to add user support, OIDC would probably be more palatable to integrate into spliit than a full user/login system.

[edmondsiu0]

I second an OIDC approach.

Even an option to accept header like "X-Forwarded-User" or "X-authentik-user" would be a super useful addition on top of forward authenticators.

[LIRIKKER]

+1 to this. Might be the push needed to create and enable user accounts in spiit with an OIDC approach. Should help resolve a bunch of other issues with this app.

• Could also look to simplify payments across various groups FEATURE REQUEST: Running Balance of All Groups with same participants #19 . i.e I owe John £150 in group 1 and £60 in group 2. I should be able to pay £210 and settle across both groups from the "People" section. In people you could do a simple friend system where you add by username.
• Also addresses FEATURE REQUEST: Ability to Share Link with Multiple Groups #20 as groups would be displayed on your homepage since a user can hold identifiable information about groups they are in.
• Look to add the user ID's on Feature request: Make transactions immutable #106 to ensure the user doing the action is actually the user they say they are.
• The complexity in Feature Request: encryption at rest #34 could be also addressed by using the users login. Option to enable encryption or not (though I do think this should be as standard without the option of turning it off)

[Soulplayer]

This would be a welcome addition for the app!

[antonio-ivanovski]

Looking to add user management feature, either better-auth or next-auth can be used to make the user management bit simpler.

The proposal I am playing with

• Introduce user management into the application. This will bring the User model.
• Groups can be marked as "protected". Protected groups can have only participants with User linked to them. Not-protected groups can have both participants with or without User linked to them.
• The Participant model would receive a one-to-one relation with User. Otherwise it remains the same. This is for backward compatibility without complex migrations.
• Protecting all the view and mutation of protected groups. This will be based on the session of the User trying to access/mutate
• Probably there should be some changes around localStorage persistance for logged in users
• Adding auth related UI elements
  • Sign-in
  • Register
  • Forgot password
  • Unauthorised
  • Group Settings "protected" toggle
  • Group Settings user management, linking existing participants to users, adding new participants by user (email)
• Email invite for users without account

[Silther]

would the user model allow to share expenses between users without a group?

[antonio-ivanovski]

After heavy use of Spliit over the holidays, got inspired to continue working on the feature, PR is open #495
Hope @scastiel will find the time to give it a review and have it merged soon