# Statement of business value <!--- Outline the business value and/or return on investment that is the result of this proposal. Structure in statement of: <proposed change> will improve <business metric(s)> by <description of mechanism> e.g. "Adding the capability for users to give cash tips will increase cash revenue and content producer engagement by generating tip commissions for Minds and cash incentives for users to produce more and higher-quality content." ---> Integrating with ActivityPub will increase network value for the Minds community by enabling people to (1) subscribe to posts created on other ActivityPub platforms, (2) broadcast posts to users on other ActivityPub platforms, and (3) interact with users on other ActivityPub platforms. Integrating with ActivityPub will also grow the Minds userbase by making it possible to port their subscriptions from another platform to Minds, where users can have better control of their algorithms and access to Minds features like Boost, Supermind, Groups, and Plus. # Scope <!-- MoSCoW specification --> ## Must have <!--- For the goal to be met, it **must** have the following criteria. Ask the question ‘what happens if this requirement is not met?’ If the answer is ‘cancel the work – there is no point in implementing a solution that does not meet this requirement’, then it is a Must Have requirement. ----> - [x] Channels can communicate between Minds and the Fediverse - [x] Posts can be shared between Minds and the Fediverse - [x] Users can follow users on Minds and the Fediverse ## Should have <!--- For the goal to be met, it **should** have the the following criteria. They are important but not vital. Without them the solution is still viable. One way of differentiating a Should Have requirement from a Could Have is by reviewing the degree of pain caused by the requirement not being met, measured in terms of business value or numbers of people affected. ----> - [x] Moderation controls - [x] Multi image support - [x] Likes/Votes - [x] Reminds support - [x] Avatar support - [x] Docs ## Could have <!--- For the goal to be met, it **could** have the the following criteria. It is wanted or desirable but less important. These are the requirements that provide the main pool of contingency, since they would only be delivered in their entirety in a best case scenario. When a problem occurs and the deadline is at risk, one or more of the Could haves provide the first choice of what is to be dropped from this timeframe. ----> - [ ] DID / Verify custody of other ActivityPub accounts and link with DID (?) - [ ] Whitelist / blacklist for ActivityPub servers (spam control) - [ ] Search fediverse - [x] Recommended fediverse users in feed component and scrollable list - [ ] Settings ## Won’t have this time - Polls - Minds migrating to a thread based system # Technical Analysis <!--- This section will usually be filled out following the completion of a Spike or Analysis task. The criteria above must be sufficiently built out before the analysis can be completed. --->