I strongly disagree because Fidonet and E-mail don’t need to teach its users they’re not centralized. The UX and UI don’t need to explanation it for users to use it effectively. For email, it’s because it’s commonplace, as many are even growing up in an environment where email has existed as a norm before they were born, as people have to understand email for some work environments, or for even getting a job. I don’t think that people think much on how email works, of knowing that it’s a federated protocol, just merely “that’s the way it works”. Hell, majority of people likely don’t even configure their own email client themself, they likely just use the vendor’s application instead. Nonetheless, federated content platforms are an emerging thing, and thus people have to ‘re-learn’ that there are different ways to intercommunicate than email.
Technically speaking, don’t even need to do that. Just have generic specific agreed upon webpage domain for this. Phones apps can intercept that URL, non-app aware browsers landing on that page (…) It’s been at least 6 years since I last touched mobile app dev. Last I remember it was an ‘Android thing’ to ‘intercept’ certain registered URLs to a mobile app, whereas I think the iOS way was only with registering custom URI schemes. It may be a big risk to trust one entity to host said address, unless they’re someone universally trusted and heavyweight enough to keep it up for near-eternity. The “Web-based protocol handler” would be a ‘web native’ way of handling it, without requiring any installed app. In fact, it can be both: if there’s registered handler for ‘web+activitypub’ (for example), it could present that URL, if not, then present the landing page handler (which Android clients could intercept and handle).