[ADR] 0001 - Adopt Multiaddr

[bryanchriswhite]

Summary

This pull request adds an Architecture Decision Record (ADR) for adopting the multiaddr addressing format to simplify and consolidate node identity in our system. The ADR explains the context, problem statement, decision drivers, considered options, and the decision outcome, along with the positive and negative consequences of the chosen option.

The chosen option is to adopt the multiaddr format as it provides a standardized, extensible, and future-proof solution for addressing nodes in our network.

Please review the ADR and provide feedback on:

• The clarity of the problem statement and context
• The thoroughness of the decision drivers and considered options
• The appropriateness of the chosen option given the decision drivers
• Any additional considerations that may have been overlooked
• Any changes in formatting, grammar, or language for better readability

[dylanlott]

multiaddr is the right choice here I think. It's a well-defined and supported format and it doesn't make sense for us to spend time reinventing the wheel.

[dylanlott]

💯

[Olshansk]

I noticed that the ADR is very light, which comes with both pros & cons.

Was it an explicit decision to not, for example, provide examples of what a multiaddr or a custom URL looks like?

I can steelman both sides of the argument here but wanted to know if it was the intention or just a lack of time?

[bryanchriswhite]

I agree, I think it was more of a matter of structure.

Looking at it now, I'm not sure where it would make the most sense to put something like that. I feel like that would be something that I would expect to be covered by references. However, there isn't a great way to consistently be much more specific with a reference other than a link to a page (and maybe a named anchor on the page). I wonder if grouping them all together is the must useful approach.

We could consider including an "examples" or "practical application" section in "decision outcome" > "positive(/negative) consequences" and/or each option section. Pos./neg. consequences would provide a place to show (or reference) code and/or diagram(s) like this. Wdyt?

[Olshansk]

Let's add a section like so with the comments I have in place. I think we should keep it light weight but have a reminder to do this if we choose to.

I think if you copy-paste one of your tests in p2p, or link to them, it would be more than sufficient in this ADR.

### Supporting Examples/References <!-- optional -->
<!-- 
This is an optional section for you to link to or embed supporting examples.
These could come in the form of positive/negative consequences or just
examples for others to reference.
-->

[Olshansk]

@bryanchriswhite Bump. Wanted to tend to the comments above but otherwise approve the ADR.

[Olshansk]

I added a few minor comments, but approving because agreed on the path forward.

[Olshansk]

@bryanchriswhite You think this one is good to merge in?