Default rad/self construction

[FintanH]

Some operations in Storage require that the default rad/self is set before performing them. I was thinking that a useful tactic might be to employ a PhantomData marker for ensuring that the default is set for an instance of Storage and those operations live under that impl.

This pushes defensive code for those checks into one place where the initialisation of the Storage happens.

[kim]

Under what circumstances is there no rad/self (that is, an identity to use as "this user's profile")?

[FintanH]

When we first construct the Peer/PeerApi it's not set -- if I'm understanding your question

[kim]

Yes, but when you `create_repo`, we try to guess it based on the `Entity` passed in. I'm not sure where it is required to have a default set -- this would be a bug: the caller would either need to specify that they wish to use the default (and get an error back if that doesn't exist), or supply it.

[FintanH]

Sorry, I think you're right. I was conflating our usage in Upstream where we use get_default_rad_self.

So, we could possibly move this type of plan there if you don't think it's a concern for the Storage API, what do you think?

[kim]

Not sure about how the onboarding flow works, but potentially it could just be **required** for upstream users to create a minimal user profile when initialising.

[FintanH]

Ya, that happens in our main entry point.

It mostly crops up when we test and haven't initialised the default rad/self 😅 Maybe we need to incorporate it into the setup of the peer in upstream.

[NunoAlexandre]

Maybe we need to incorporate it into the setup of the peer in upstream.

That seems like the right thing to do yeah