Some Initial Questions About FAIR  ## Metadata - Author: [[jorbin]] - Full Title: Some Initial Questions About FAIR - Category: #articles - Document Note: --- tags: - #wordpress - #opensource - #fairproject - #FAIR Author: Aaron Jorbin Source: https://aaron.jorb.in/some-initial-questions-about-fair/ Reference: https://aaron.jorb.in/some-initial-questions-about-fair/ date created: 2025-06-11 18:00 --- # Title: Some Initial Questions About FAIR ## Table of Contents:  - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ## 📝 Summary: Aaron Jorbin congratulates the FAIR team on reaching their 1.0 milestone and shares a thoughtful list of open questions regarding FAIR’s protocol and implementation. His queries cover areas such as moderation of bad actors, handling duplicate plugin/theme names, standards and governance of aggregators, transferability of plugin ownership through Decentralized IDs (DIDs), trademark concerns with repositories like GitHub, release confirmation processes, and decentralized review mechanisms. The post invites the community to collaborate on these evolving challenges, highlighting that FAIR is still a work in progress, designed to improve over time. ## 📖 Main Content: The article serves as an early critical reflection on the FAIR Package Manager Project following its initial release. Aaron expresses enthusiasm but emphasizes the importance of clarity around governance and technical details yet to be fully addressed. He frames his questions as essential to understanding how FAIR will manage security threats (bad actors), prevent confusion from naming collisions, and maintain quality and trust in a decentralized ecosystem. Jorbin explains the concept of Decentralized Identifiers (DIDs), detailing their role in package ownership and portability, and notes the limitations of certain DID types (like Web DIDs). He also discusses moderation as a layered service, with inspiration drawn from BlueSky’s AT Protocol, allowing users to subscribe to moderation services that fit their needs, including potential paid options. Regarding reviews and reputational systems, the post acknowledges the complexity and lack of a finalized approach, suggesting that multiple third-party review platforms might compete and coexist. Overall, the article balances recognition of FAIR’s achievements with an honest assessment of open questions critical for its success, inviting dialogue and community collaboration. ## 🗒️ Notes - **Praise and Milestone:** - FAIR reaching 1.0 is a significant achievement. - **Moderation and Security:** - How to report and handle bad actors in federated repositories? - Concept of layered moderation services (e.g., security scanners, paid moderation). - **Naming Collisions:** - Potential conflicts if different aggregators accept the same plugin/theme name. - Possible solutions include domain-based verification (like BlueSky’s approach). - **Aggregator Standards:** - Aggregators act more like search engines; users choose which to use. - Standards and exclusion policies likely to be set by individual aggregators or moderation layers. - **Decentralized Identifiers (DIDs):** - DIDs link to repo locations and signing keys; enable data portability. - Web DIDs are immutable and less flexible; PLC DIDs preferred for transferability. - **Trademark Issues:** - Github is trademarked; implications for DID naming and rebranding. - **Release Confirmations and Workflows:** - FAIR protocol leaves release workflow details to individual repositories. - **Decentralized Reviews:** - No centralized review system planned; could have multiple third-party review services. - Challenges include preventing sock puppetry. - **Community Engagement:** - Encourages joining GitHub discussions for ongoing collaboration. - Acknowledges answers will evolve with community input. ## 📖 References: - Jorbin, Aaron. "Some Initial Questions About FAIR." aarom.jorb.in. June 9, 2025. https://aaron.jorb.in/some-initial-questions-about-fair/ - BlueSky AT Protocol documentation. - FAIR Project GitHub repositories and discussion forums. ## 🗣️ Paraphrase:  1. Original: "How does someone report a bad actor in a federated repository? If I discover someone who is acting in bad faith, do I need to track down every discovery aggregator, inform them independently, and have each do its own investigation before users are protected?" Paraphrase: What is the process for reporting malicious behavior in a federated repository? Would I need to notify each aggregator separately and rely on them individually to act before users are safeguarded? 2. Original: "The release process is up to the repository itself. We expect there’ll be repositories with full workflows, and others with a minimal release flow." Paraphrase: The management of software releases is determined by each repository. Some may implement comprehensive workflows, while others might opt for simpler, minimal processes. ## 📰 Newsletter: Hey WordPress community! 🚀 Aaron Jorbin, a respected core contributor, offers a candid look at the early questions surrounding the FAIR Package Manager Project’s launch. His thoughtful inquiries span moderation of bad actors, handling naming conflicts, standards for aggregators, transferability of plugin ownership, and decentralized review systems. FAIR is shaping up as a flexible, federated approach to plugin management, but as with all pioneering projects, many details remain to be hashed out through community collaboration. If you want to stay informed on FAIR’s development and help shape its future, check out Aaron’s detailed questions and join the conversation here: https://aaron.jorb.in/some-initial-questions-about-fair/. Your input matters! ## ✅ Action Items: - Use Aaron’s questions as a foundation for educational content explaining FAIR’s governance and technical complexities. - Facilitate community discussions and workshops addressing FAIR moderation, security, and naming challenges. - Promote transparency around decentralized identifiers and ownership transfer mechanisms in WordPress contexts. - Advocate for development of standardized review and moderation services within the FAIR ecosystem. - Incorporate these foundational concerns into OSPO advocacy, focusing on sustainable governance and contributor inclusion. - Align messaging with your goals of fostering psychological safety and trust in open source communities. ## 🧪 Hypotheses: - Layered moderation services improve security and trust in decentralized open source ecosystems. - Clear standards and verifications reduce user confusion in federated plugin repositories. - Decentralized review platforms encourage diverse community feedback but require robust anti-abuse mechanisms. - Data portability enabled by flexible DID methods enhances ecosystem resilience and ownership transfer. ## 📊 Methodology: - Analyze community reports and outcomes related to bad actor moderation across federated repositories. - Survey users for confusion or errors due to naming collisions and test efficacy of verification methods. - Experiment with different review platform models and measure influence on user trust and contribution. - Evaluate DID implementation impacts on plugin transfer workflows and user adoption. ## ❓ Questions: - What specific moderation tools and workflows will FAIR implement to handle security threats? - How will FAIR ensure global uniqueness of plugin/theme names across independent nodes? - What minimum standards will FAIR aggregators adopt, - Summary: Congratulations to the FAIR team on thier launch. 1.0 is the lonliest number, so getting to to this milestone is something for them to celebrate and I hope the team behind it feels great about getting this far. One of the best parts of getting to a public release is that you start getting feedback […] - URL: https://aaron.jorb.in/some-initial-questions-about-fair/ A large, colorful question mark made up of various small figures and objects stands prominently in the foreground. Surrounding it, a group of humanoid figures in muted colors gazes at the question mark, creating a sense of curiosity and contemplation. The background features a rocky landscape with distant mountains and a cloudy sky, enhancing the scene's dramatic atmosphere. Congratulations to the [FAIR](https://fair.pm/) team on thier launch. [1.0 is the lonliest number](https://ma.tt/2010/11/one-point-oh/), so getting to to this milestone is something for them to celebrate and I hope the team behind it feels great about getting this far. One of the best parts of getting to a public release is that you start getting feedback from real users. Some of that is coming out and I’m sure I will have some to add, at this point I don’t yet have a solid opinion on FAIR. What I do have are some questions I haven’t found the answer to while reading the [protocol documentation](https://github.com/fairpm/fair-protocol). I am hoping someone can either point me to the documentation for each of these or answer directly while I continue to digest as much as I can: 1. How does someone report a bad actor in a federated repository? If I discover someone who is acting in bad faith, do I need to track down every discovery aggregator, inform them independetly, and have each do its own investigation before users are protected? * For this purpose, I’m using Bad Actor in all of it’s possible meanings including introducing intentional and unintentional security issues, hacked accounts, and people being jerks. 2. What happens if different aggregagtors accept the same name for a plugin/theme? What can be done to prevent user confusion? * I think this is also important since someone doing local development with one aggregator but using a different in production feels like a distinct possibility. 3. In order to be listed in the plugin, is there a standard for the aggregator and the standards that they set for inclusion? * Similiarly, how will these standards be monitored for potential exclusion later on? 4. If the **Decentralized ID** is based on the repo, does that mean you can not transfer ownership of a plugin? * The [documentaiton states](https://github.com/fairpm/fair-protocol/blob/main/specification.md#resolving-dids) “Vendors SHOULD use DID methods that are future-proof for data portability, and which avoid encoding trademarks or potentially-ephemeral names or domains.” Does this mean that Github should be avoided since it is a trademark? 5. Does FAIR have a concept of release confirmations or other 2nd factor for releases? 6. How do reviews work in a decentralized manner? If I have an opinion on a plugin, will I need to share it with all aggregators? * On a similiar basis, if reviews are going to multiple places, what is the plan to combat sock puppets? I imagine some of these are questions that will need to get answered over time, and also that for some, today’s answer may not be tomorrow’s. As with all open source projects, I can only imagine FAIR will change over time. #### GET AARON IN YOUR INBOX ##### One response to “Some initial questions about FAIR” 1. These are all fair questions! 😉 I’ll try and tackle them as best I can here, but please do come join us in the Discussions on the [GitHub repos](https://github.com/fairpm/fair-protocol/discussions) and [org](https://github.com/orgs/fairpm/discussions) 🙂 (Also: with all of these responses, treat them as draft responses – we wanted to launch without having all the answers, so we can collaborate on them as a community.) Our plan is to take inspiration from Bluesky’s AT Protocol here, where individual repositories moderate what they host, with an additional “overlay” of moderation services on top that you could subscribe to (probably with a default too). You could, for example, then also subscribe to a security scanner moderation service that could do advanced checks and only let you install safe plugins – going beyond what’s possible with today’s moderation. (e.g. Tide could have been a moderation service, or a security company like Wordfence or Patchstack could offer a paid moderation service) Aggregators are more like search engines than decision makers, so really this is more of a question of “what happens if different vendors pick the same name?” This is one of those classic decentralisation things, and we’re looking at different ways we could tackle that. One way is again to copy what AT Proto does with domain name-based verification, so you could eg say “this plugin is verified as sitekit.google.com”. Thoughts very welcome on alternatives, and we’re also keeping an eye on what other decentralised protocols are doing too (eg Bluesky’s new verifications). Similar to the previous, think of aggregators more like search engines. We’ll probably have an aggregator we provide, and let users switch between them. Because the choice is with the *user*, and it’s decentralised, there’s not necessarily a need to have a standard for everyone. We’ll probably set one for an aggregator we provide (and have it be very similar to dotorg’s). With moderation also separated out, you could move some of the decisions about standards there; for example, you could have a moderation service that only allows packages which have an ethics statement. > If the Decentralized ID is based on the repo, does that mean you can not transfer ownership of a plugin? > > DIDs aren’t based on the repo; rather, the DID tells us where to find the repo (along with which keys are valid). This means you have data portability. An example DID would be `did:plc:ia6vk5krwkcka2nwuzs6l6lq`. The plc part of this tells us it’s the PLC Directory, and you can look it up there: <https://web.plc.directory/did/did:plc:ia6vk5krwkcka2nwuzs6l6lq> You’ll see that this lists which repository to use (`https://fairpm.example.com/` in this example), along with which signing keys are valid (verification methods) for checking packages. To move to another repository, you just need to change that URL. (You do this via a tool, probably an “import existing package” tool in your new repo.) The other type of DID we support is Web DIDs. These look like `did:web:aaron.jorb.in:some:path:name`, which would map to the URL `https://aaron.jorb.in/some/path/name/did.json` These don’t use a directory like the PLC method, but the downside is they can never be changed. If you were to eg sell that plugin to someone else, or move your site to a different domain, you can’t change your Web DID. We recommend using PLC DIDs instead for that reason. The mention of trademarks in the docs is more for rebranding; for example, if you rebrand from “Jorbin’s Excellent Plugin” to “Excellent Plugin by the Excellent Team”, you wouldn’t be able to change the Web DID to match. Comment \*, Some Initial Questions About FAIR, jorbin, 01jxgfxwpekm20fyrfty6c6avf.