#Family/Group space or Shared Account

1 messages · Page 1 of 1 (latest)

crude dove
#

ping <@&980972470964215870>

#

Thank you for posting here, this is quite a complex feature/mechanism so having feedback from the group would be great

#

What is non-interactive account?

last inlet
#

This seems closely related to the upcoming multi-library functionality and the concept of being able to access a library from multiple users

#

It's just an idea at the moment, but I don't see why not

#

The base for multilibrary is in the works right now

neon hornet
#

Does your implementation allow viewing combined data or just easy read only account switching/sharing?

#

Can the non interactive account view a main timeline for another user ?

#

Oh, so this is a single library with multiple logins

crude dove
#

What is the different of this feature comparing to a shared album?

neon hornet
#

I am not following it seems. It is unclear to me what logins exist and what logins see what photos.

last inlet
#

The idea here is as an alternative for partner sharing, right?

#

No rush 😛

neon hornet
#

Do you have a published branch I can just look at?

crude dove
#

Immich has its best thanks to peer reviewed nature 😛

neon hornet
#

If you push it as is I can take a look and translate the features into immich speak 😛

crude dove
#

You can set it as draft

neon hornet
#

You don't have to open a PR, just push your branch

last inlet
#

I'll lay out the multiple libraries angle of how this (partner) asset sharing could work. The base of this is being built right now, most of it is just ideas. This is how I have it in my head so it could be wrong on some details, @sweet adder do correct me if needed :)

Currently, an Immich user has one (implicit) library that all files are uploaded to. Work is being done to allow having multiple separate libraries. One can be read-only, one can be the library your uploads go to, etc. Then in the 'main' Immich pages, you just see all the assets from all the libraries that you have access to.

In the future, there's a bunch of stuff that can be added to this, such as 'hiding' a library from the main views. What's relevant here is that we could make it so that instead of one library belonging to one user, you can have a library that many users have access to. Then you automatically get all those assets in your main view (or if you hide the library, you could find it in a separate view similar to how the current partner sharing implementation works).

How does that approach compare to what you're trying to do? I think they overlap in the problem they're trying to solve, and I'm wondering by how much :)

#

I hope that helps/makes sense

crude dove
#

So user A and user B know about user C's username/password?

#

How can you get to that interactive account?

#

Like an account switcher on the user profile on the top right?

#

ok got it

#

How do you "ingest" the asset to the interactive account?

#

what happen if the assets get removed from the owner's account?

#

Ah so the interactive account is just an account that cannot be logged in directly?

#

What is the different of this feature from creating a "shared account" and share the login credential with family member so they can contribute to that shared account, besides the faster switching flow

#

How can you login your primary account if you disabled password auth?

silent parrot
crude dove
#

So you can use SSO for that shared account too, correct?

silent parrot
#

No

#

The way I understood is the following:

A account is linked to an Google account A
B account is linked to an Google account B
C account is linked to B and A via the account that one cannot login directly with in Immich.

Auth works so that when account A logins via Google Account A, they actually see things from C account.

crude dove
#

Can you create a shared account for SSO that can be used by the family member?

silent parrot
crude dove
silent parrot
#

Which is why I said pain and more pain. 👆

crude dove
#

Correct, I don't see that would be a blocker?

#

you authenticate on the device just once

silent parrot
crude dove
silent parrot
crude dove
#

You just need to share/authenticate that shared email address, right?

#

you don't share your personal account on others device

silent parrot
crude dove
#

how can this be?

silent parrot
crude dove
#

I am being a devil advocate here to see if we exhaust all possibilities

crude dove
silent parrot
crude dove
#

my take is that I see this feature is very niche and the added complexity is my concern

silent parrot
#

I think there should be a proper mechanism to do this without "swapping" things on the auth.

#

I think one appraoch could be like:

User A with library A
User B with library B
User C with library C

Then allow each to upload to a shared library D but also keep photos in their own library if they so want.

#

I can imagine that most families might want a larger shared library and teens might want their own library as well for example (that doesn't get shared automatically).

crude dove
#

I will wait for more thoughts from others

silent parrot
#

Can you currently NOT use it?

#

Can you have accounts without the swapping auth thing?

peak kraken
#

So, from what I understand this would be kinda covered by the shared library feature from @sweet adder. Ultimately, the goal there is to be able to share libraries (right?), both in a unified library as well as a library switcher. With this, within your regular account, you could have your private library as well as (more or less complete) access to shared ones.

#

Is this kind of similar behavior to what you'd expect? @spice monolith

#

The owner would probably be the one who uploaded it (?) but all other things should be there too, yes.

#

This I don't know about.

#

I'm still quite new to this and only read a little in the issues/forums. So this would be a question for the core devs/etnoy

last inlet
#

#1145363766825988146 message

silent parrot
peak kraken
#

Search should work for all libraries from what I understand, explore probably as well (?), though most likely not in the first iteration?

last inlet
#

I think everyone did :D

#

So I'll ask that people go back and read that, as I think it's very important to the discussion

peak kraken
#

@last inlet Oops, I guess I basically just retold most of what you've already wrote...

silent parrot
#

Sounds like a huge pain tbh due to how fast things are evolving with Immich.. :D

neon hornet
#

To me the catch is all the API logic replies on authUser.id for all the queries. Proxying at the auth level makes sense. We might be able to be it a bit cleaner though. The general idea is login with account A, but get a token that indicates access is for account B. Now individual accounts can login and control the same account B

last inlet
#

I'm not really a fan of merging something when we know we're going to delete it in favour a different approach pretty soon, I would rather just apply a bit of patience 😅

#

Nope

peak kraken
#

@spice monolith How is your workflow of creating such a "shared account"?

#

So the admin user can create such accounts and then assign mail addresses/oauth credentials to it?

#

Well oops

last inlet
#

There can be multiple admins, there's just no UI for making that happen

neon hornet
#

Libraries doesn't solve everything now. It is similar to partner sharing in that the second user wants to be able to favorite assets and track those separately from the owner. Sharing this way is different from "family space", which effectively has a single owner and set of favorites.

last inlet
#

So it would be similar to this

neon hornet
#

That hasn't been decided or implemented yet.

last inlet
#

Indeed

#

But at the moment favourites are per-assets, and assets would belong to a library

#

So that's the natural state, unless we decided to change how favourites work

neon hornet
#

There is a ticket to let shared users independently favorite stuff.

#

The question is should separate users have separate albums, favorites, assets, etc. This is how we currently envision it working and have designed everything. I think there is a valid use case for multiple users sharing access to albums, favorites, archived status, etc

#

The PR implements a way in which all users share all albums, etc.

last inlet
#

But with libraries you can have both, right? You can have your own personal library that's all yours, or you can have a shared library that's all shared

neon hornet
#

Libraries doesn't do anything revolutionary. It is simply segmented groups of assets.

#

It doesn't solve anything related to albums and all queries still use the current logged in user. Library sharing will require a separate table for tracking sharing just like partner sharing, etc.

#

It is still user first not content first

last inlet
neon hornet
#

The whole idea is to make it possible to auto scan sync a group of assets. After that it is just hype imo lol

last inlet
peak kraken
last inlet
#

asset -> user

#

My understanding is that libraries will make that
asset -> library -> user

#

where library -> user could be to many users in the future

#

and then same for album -> library etc

#

What do you mean?

neon hornet
last inlet
#

I still don't get what you mean - assets currently have a direct relation to the user

#

That would be replaced by a relation to a library

#

Which can then link to many users

peak kraken
neon hornet
#

If there anything the original PR solves that would not be solved by sharing a third account and adding an account switcher to immich, so you could be logged into two accounts at the same time?

crude dove
#

From my point of view, this is a complex mechanism to add to the code base to serve a niche use case. From the development standpoint, if any decision has to be made, I would wait until after the library PR is implemented and merged, since it has be under the work of many months and many people. I would take it with a higher priority https://github.com/immich-app/immich/pull/3124

neon hornet
#

To me it seems like the PR makes it possible to access account C while logging in with account A or B. We could accomplish basically the same thing by making it easy to switch between two logged in users.

crude dove
neon hornet
#

Just not via a password, right?

crude dove
neon hornet
#

Boooo, just use a third account and call it a day (after we implement a switcher)

polar agate
#

i like the account switcher idea. it would accomplish a similar thing without the complexity here.

crude dove
last inlet
last inlet
#

You click the account icon in the top right, and it shows other accounts that you're also logged in to, which you can then switch to

#

Similar as on google/youtube

neon hornet
#

Is that a problem?

#

I have a family Google account that we're all signed into.

#

But you are signed in with your personal one?

last inlet
#

Nobody's saying you should log in someone else's account on your system

#

But rather, that you create a new account just for everyone to share

neon hornet
#

Obviously we cannot add every single feature everybody wants to immich. So it comes down to prioritizing features based on the complexity of the implementation, how many people need/want it, the tradeoffs between it and other solutions, if there are other related features that would benefit from it, etc.

So far your suggestion can be 98% replaced by an account switcher, which is a common thing for apps to have and requires no server side changes and minimal client side changes.

last inlet
#

^To add to that: We need to be pretty critical about what we add to Immich. If we merge everything anyone suggests (even if it is a good idea well implemented) things will be a mess in no time. If we can do something for 98% with a way simpler approach, that is almost always the way to go.

neon hornet
#

I am just trying to understand the tradeoffs between that and your solution and why an account switcher would not be a suitable substitute.

last inlet
#

We do appreciate your effort and intent, I want to make that clear!

neon hornet
#

In general, the simpler the auth implementation the less chance there is for auth bugs. If you are concerned about security you should also consider the security implications of doing something like this, which seems very non standard. Are there any other applications that do something like this?

#

The approach no, the implementation yes. Trello doesn't use "non-interactive" accounts.

#

They separate users from data and use many to one relationships to abstract access to it

#

I think you are missing the point though

#

Ah, my bad.

#

Your feature request is more like "login to the same account with different emails" unless I don't understand what you are trying to accomplish.

#

If you want all the functionalities of a shared account without requiring to share passwords that is basically what you are describing

#

Yes, you want everyone to use a "shared" account, but auth to it from individual accounts

crimson sequoia
#

I don't like the idea of one account for multiple people

neon hornet
#

I think the use case is valid, a family wants to login and see shared content. I'm not sure what the best implementation should be though. With the current design you can already accomplish this with account sharing, and adding an account switcher seems like a good idea. Long term I think it makes sense to have albums and assets be automatically shared via features like groups, users, and libraries.

peak kraken
#

If I may add, I feel like having an account you cannot login to directly but multiple users can login to through their account is just a "hacky" replacement for groups.

crimson sequoia
last inlet
#

There are many more considerations to merging something than just "will this make people happy". There are other ways to accomplish the same that will also make people happy, but might be cleaner/more maintainable in the code, or other factors.

#

We're not in a rush, so speed isn't really an argument

crimson sequoia
#

Immich has a lot of feature requests, i'm sure it will be implemented at some point.

last inlet
#

then someone else can improve it
The caveat here is that doing that improvement is most likely to fall onto us maintainers, and we're few people with many things to do already.

neon hornet
#

If this was a step towards groups it would be fine to merge. Most likely we would have to delete all your changes when we implemented groups.

crimson sequoia
#

at some point, there has to be a consensus 😄

neon hornet
#

Libraries is potentially a step towards groups as it abstracts the ownership piece of assets

#

I have a problem with adding it to the codebase though.

crimson sequoia
#

Even if OSS is not known for adding new features quickly, Immich is by far the project that I know that adds them the fastest

last inlet
#

I don't think popularity makes us more likely to merge a PR. The point here is that there are other ways to solve the problem that this change solves, and we would rather explore those. I think most people who would add to popularity just want this problem solved, and don't particularly care about how it is done exactly.

#

You're welcome to make a PR of course, but there might be better uses of your time

#

With all due respect - your opinion holds less weight than those of the maintainers, and the maintainers prefer to try another approach

neon hornet
#

Can you explain what you mean by two level album sharing? I don't follow that.

#

What is the two levels though, I don't follow

#

User A and User B can share albums with User E?

peak kraken
neon hornet
#

This is "account sharing" and then album sharing?

peak kraken
#

They account share C and share C's album with E

crimson sequoia
#

@spice monolith How do you see managing the change of password with your solution?

last inlet
#

That would still be possible with just a shared normal account, right? I don't see how it's unique to your login approach

crimson sequoia
#

It should be disabled ?

neon hornet
#

Account C has login disabled in the PR.

#

The thing that is interesting is you have basically created one to many relationship between users and a user "not interactive", in order to avoid any of query changes in the rest of the code. Alternatively we could put this abstraction between users and assets for the same effect.

#

You need something between users and assets. You chose user => user => asset.

last inlet
#

I vote user -> library -> asset 😛

neon hornet
#

Or user => group => asset

#

User belongs to a group and assets belong to a user and a group.

crimson sequoia
#

This sounds like how bitwarden manages groups

peak kraken
neon hornet
#

The current PR is simple in that it avoids changing any of the existing queries, which is where the complexity exists. That will be required to "do it right".

#

Complexity in the implementation while keeping performance probably.

crimson sequoia
#

Sounds like a "hack" before an official implementation

polar agate
#

i think this would have benefited from a focus discussion before writing this pr so we could plan on the best approach

crimson sequoia
#

If it does not bring bugs and misunderstanding I'm ok with it

#

You did well !

#

Even if it's not merged, it's interesting to see how you implemented it

last inlet
polar agate
#

compared to features like groups, libraries, account switching, etc., this seems like a short-term solution that can make implementing future changes in this area more complicated. i'm thinking of it as a proof-of-concept for groups that would need to be reworked to be an actual group instead of a user.

last inlet
#

Personally I would like to wait and see how the libraries functionality pans out before exploring other avenues for this sharing question

#

Although the account switcher option mentioned by @neon hornet seems fairly simple and self-contained, I wouldn't be opposed to that