Feature Request: Proactively detect and notify users without a contact list

[danieldaquino]

As a Damus user who unfortunately never got a contact list (See https://github.com/damus-io/damus/issues/2057 for context), I would like to be notified about the "First Aid" solution, so that I can be aware of what is wrong with my account and get a chance to fix it.

Is your feature request related to a problem? Please describe. It is related to https://github.com/damus-io/damus/issues/2057

When does this problem happen?

• When users had connectivity issues when they signed up (See https://github.com/damus-io/damus/issues/2057)
• When contact lists are deleted from relays

Describe the solution you'd like We should try to detect cases where we suspect a user's contact list cannot be retrieved, and somehow notify them of a problem and suggest them to reset the contact list through the "First Aid".

This is tricky because:

• a lack of contact list could simply mean a temporary connectivity issue or relay outage.
• Resetting the contact list when one exists causes the user to lose the list of everyone they followed and every relay they connected to.
• We cannot take too long to make this detection because most people will just quit the app quickly thinking that the app is broken.

We will probably need a mix of monitoring relay connectivity, contact list presence, and some time delay that isn't too large (user quits the app) or too small (false negatives)

Describe alternatives you've considered

• Just letting the user come to us for support?
• Automatic detection and fix (dangerous, there could be false negatives)
• Perhaps something else?

Additional context

• https://github.com/damus-io/damus/issues/2057

[danieldaquino]

@jb55 @alltheseas I created this issue based on what we discussed this morning.

Are we planning to target this to 1.8 or 1.9?

[alltheseas]

@jb55 @danieldaquino I recommend this go to 1.8 if we can do it by May 1st (keeping in mind potential additional AppStore iOS requirements & delays as mentioned by Daniel), otherwise add to 1.9.

[alltheseas]

@danieldaquino great work systematically detailing what exactly you are working on, and what the issue is!

For the most part with user stories I keep these user centered (i.e. where the user is the person using the Damus app - user is the "consumer" or "customer"). Usually user centered stories revolve around what the customer wants - e.g. zaps, subscriptions, animations etc.

Sometimes we have user stories where the user is not the social media enjoyer. For instance we could look at this story from the lens of you/Will as the maintainers / lead devs of Damus iOS. You could write the story with the same end goal, without the consumer ever being aware of this safety feature existing. e.g. "As Damus lead dev, I want to prevent an unhappy path/help prevent limbo state etc.."). More often that not, I label these as "technical" on github issues.

No need to change anything, the way you wrote it is great and more clear that I could ever write the same spec.

P.s. I think you are the first to fully write the feature request template, thanks for being the guinea pig :). Let me know if it's too much, and if we should remove/edit anything from it.

[jb55]

On Fri, Apr 26, 2024 at 11:40:36AM GMT, Daniel D’Aquino wrote:

@jb55 @alltheseas I created this issue based on what we discussed this morning.

Are we planning to target this to 1.8 or 1.9?

1.9 is fine, the most important thing is that we now have a place to direct users if things go wrong.

[danieldaquino]

For the most part with user stories I keep these user centered (i.e. where the user is the person using the Damus app - user is the "consumer" or "customer"). Usually user centered stories revolve around what the customer wants - e.g. zaps, subscriptions, animations etc.

Sometimes we have user stories where the user is not the social media enjoyer. For instance we could look at this story from the lens of you/Will as the maintainers / lead devs of Damus iOS. You could write the story with the same end goal, without the consumer ever being aware of this safety feature existing. e.g. "As Damus lead dev, I want to prevent an unhappy path/help prevent limbo state etc.."). More often that not, I label these as "technical" on github issues.

No need to change anything, the way you wrote it is great and more clear that I could ever write the same spec.

P.s. I think you are the first to fully write the feature request template, thanks for being the guinea pig :). Let me know if it's too much, and if we should remove/edit anything from it.

Thanks @alltheseas, I like this format! I guess if something doesn't apply we can always put "N/A", but it's good to have the prompt so that people can provide a good amount of detail

I think it will definitely help for feature requests coming from users

[danieldaquino]

On Fri, Apr 26, 2024 at 11:40:36AM GMT, Daniel D’Aquino wrote: @jb55 @alltheseas I created this issue based on what we discussed this morning. Are we planning to target this to 1.8 or 1.9? 1.9 is fine, the most important thing is that we now have a place to direct users if things go wrong.

Thanks for confirming @jb55, I will move this to the 1.9 milestone then