What's the best way to know if you're still only on the initial project?

[achou11]

We currently do a rather fragile check to determine if the user hasn't explicitly created a new project and they're still on the "initial" project:

https://github.com/digidem/comapeo-mobile/blob/d2cae1759edb7c63d8a0c6ae8168ee1720d7fd9a/src/frontend/screens/Sync/index.tsx#L59-L66

This will eventually break when we introduce the ability to properly leave the "initial" project (UI introduced via digidem/comapeo-mobile#162 but actual functionality will be introduced via digidem/comapeo-mobile#525).

There are a couple of ways to go about this off the top of my head:

1. client-side approach: store the project id of the initial project in client-side storage (e.g. MMKV, secure storage, etc). what happens if the relevant entry is deleted or lost?

2. server-side approach: expose some kind of option in the core api when creating a project to essentially label a project as a "private" project i.e. not intended or possible to share with others. Not sure how keen i am on this approach because ideally core shouldn't really care about this, as it's kind of application-specific.

[EvanHahn]

Solutions in order of preference:

1. Reliably infer whether this is the initial project. (I think this is impossible.)
2. Store the value in @mapeo/core.
3. Store the value on the frontend.

I prefer to store this in @mapeo/core for two reasons:

• It's hard to keep data in sync, even in the same program. Imagine you create the initial project and then the app crashes before you can write its ID to MMKV, or that there's some other bookkeeping that goes missing as you mention.
• @mapeo/core already does so much for the frontend, so this doesn't feel weird to me. Since I've been here, we've made large changes in this space¹. I think this is good, but I admit this is a more philosophical question about this module's goals.

Footnotes

1. such as inverting peer discovery (9a523e5) and app background/foreground detection (bb9b16c) ↩

[achou11]

@EvanHahn yeah i think what you've outlined makes sense. there's probably a way to add support for this in core without it being too tied to application-purposes but agree that we're already kind of deep in it in terms of how tied to comapeo it is, so probably doesn't matter too much overall.

i guess then the basic ask here is where does this kind of information live? my guess is that this would live in the client or project database

[EvanHahn]

Yeah, maybe on that ProjectInfo type? Not sure.

[tomasciccola]

There's two places on the top of my head where we could add this:

• DeviceInfo
• ProjectSettings

I should check how we set projectSettings. e.g. if when starting mapeo, before joining a project, we call setProjectSettings or if we call it only after explicitly joining a project.

if we add it to DeviceInfo it could be smth like boolean joinedProject. If on ProjectSettings it could be smth like boolean onInitialProject or isInitialProject.
Don't have much preference though...

[EvanHahn]

My gut says to put it on ProjectSettings, but I don't really know why I think that. I guess it's specific to the project, not the device? And theoretically you could have multiple "lonely" projects?

[tomasciccola]

could you have multiple "lonely" projects? I'm wondering if that means multiple and unrelated ProjectSettings docs in the db. What I mean is, is there a 1:1 relationship between MapeoProject and ProjectSettings (not super related to this issue, I would move forward with ProjectSettings.isInitialProject

[EvanHahn]

I think there's a 1:1 relationship between MapeoProject and ProjectSettings. I don't know if you could ever have multiple "lonely" projects.

[tomasciccola]

I imagine there's a reason, but couldn't help wonder why is there a need for a user to always be in a project? Couldn't just like, not be in a project when starting the app? Or is there some reason for that being hard??

[EvanHahn]

I don't think there's a technical requirement. I think we want people to be able to use the app on a "lonely" project before inviting others.

[gmaclennan]

Just found this now when reviewing mapeo schema code. The problem with this is that this data syncs. The concept of "isInitialProject" only makes sense on the device that created the project. I know currently we do not allow the initial project to sync, but that could always change. The concept of "initial project" is device specific, not project specific.

Two ways forward:

1. Just leave this in there, and deprecate the field in future versions. Will have to think about how v1 clients will deal with this.
2. Remove this now and change the frontend.

I think option (1) is probably preferable at this stage.

Re-opening for now, we can close when we agree on a way forward and open another issue for that.

[gmaclennan]

I think the issue behind this problem needs resolved in a UX change. I'm not sure when exactly the concept of a new user needing to "create" a project, rather than just inviting users to their current project, came in, and it would benefit from a review at some point.

[EvanHahn]

Good point, this is a bug waiting to happen.

I agree that I think the best path forward would be to leave it as is, even though it's imperfect. If the MVP were farther away, I'd say do it now, but we plan to release very soon.

[EvanHahn]

I assumed, wrongly, that the frontend was already using this value. I'll plan to remove it tomorrow and have the frontend store the value instead.

[EvanHahn]

Removed in https://github.com/digidem/mapeo-schema/pull/253.