CIP-0155? | SRV Registry

[coot]

Summary

This CIP proposes SRV prefix registry to foster discoverability of DAPs which
have their own decentralised network running along-side cardano block-chain.

Link to rendered proposal

[ch1bo]

I like the idea and Hydra could support this. I think it's most useful to open protocols though where we would want to enumerate all registered services using such certificates (info on how to register and query that registry through the ledger would be interesting). Currently, Hydra is using statically configured topologies only and if I understand this mechanism correctly this does not make much of a difference when sharing connection info (sharing a domain name vs. sharing a hostname/ip). Definitely useful for full on overlay networks where we also want to register services for longer (mithril?)

[rphair]

@coot I've titled this PR as a CIP because everything about it is following the CIP form... but if the Draft period suggests it is really a CPS then please feel free to change it.

In any case after you take it out of Draft mode we'll tag it Triage after a format double-check (there are currently some things missing) which will set it up for public discussion at the next CIP meeting.

[coot]

It is a CIP, and I just wanted to gather initial feedback first - hence a draft.

[rphair]

OK, a good way to get diverse feedback is to bring it up @ the CIP meeting (next one in 90 minutes) so I've marked it as Triage to put it on the agenda (we can remove the label to withdraw from active review any time): https://hackmd.io/@cip-editors/111 - @coot you are invited & hope not too short notice; otherwise we will do our best to understand it from quick reading.

[rphair]

@coot from our reading at the meeting under the clock: aside from @Ryun1's format suggestions above which are universal for CIPs, we had to use our imagination to determine what this CIP was about... including the connection with SRV records that a few of us know from DNS experience in a different context.

So although you might have been hoping for technical feedback about the principle itself, the main feedback was that more background could be given about the terms used, and who would be using these methods, and for what.

• For instance: some SPOs who've used SRV records to configure their stake pool relays might look over this CIP without knowing whether it's applicable to them unless something is put in the Abstract to define the target audience and/or applications of the idea.
• If that's clear when this comes out of Draft mode then it would help us tag other potential reviewers for more detailed technical feedback.

I'll take the Triage label off now & we'll reapply it as soon as out of draft & ready for review in your opinion. Personally I'd like to have a better technical understanding of your proposal but would prefer to try again when there's some more background info here.

[jpraynaud]

@coot I believe that we should make a clear distinction between the DMQ node and Mithril nodes:

• The DMQ node could be utilized by various protocols, with SRV records used to advertise the DMQ host and relays for each protocol.
• Mithril nodes (signer and aggregator) could also use SRV records, but for different purposes, such as discovering available aggregators.

It may be necessary to define multiple entries per service in the SRV Prefix Registry:

service	scope	SRV prefix	Status
cardano		_cardano._tcp	Active
mithril	dmq	_dmq._mithril._tcp	Active
mithril	aggregator	_aggregator._mithril._tcp	Active

Additionally, regarding DMQ: would this imply that the DMQ node also needs access to the ledger state (which is not currently planned)?

[coot]

@rphair, thanks for your feedback. I'll update the CIP and clarify the target audience and how it can be useful for SPOs.

[coot]

@jpraynaud As I understood dmq is universal, it might be used by different DAPs, so we shouldn't register it in the registry, instead each particular DAP should have it's own entry. But maybe that's my aberration 😉.

This registry is only helpful for DAPs that want to utilise the ledger peers.

[coot]

@jpraynaud what about:

service	scope	SRV prefix	Status
cardano		_cardano._tcp	Active
mithril	dmq	_dmq._mithril._cardano._tcp	Active
mithril	aggregator	_aggregator._mithril._cardano._tcp	Active

[coot]

@ch1bo, @rphair, @rphair, @jpraynaud I addressed your comments.

@rphair I might need a bit more guidance what should be made clearer. It's hard for me to know what is unclear without more insight. Anyway, I added a few sentences on how the SRV Record Registry will be needed by SPOs and DAPP developers.

[rphair]

@coot as both an editor and an SPO I think what you have added in this push clarifies the purpose & process of the CIP well enough.

I've marked it Triage to put it on the agenda for the next meeting (https://hackmd.io/@cip-editors/112) which you would be welcome to attend if it suits you.

I think this is a sound document & proposal so plan to suggest at the meeting that it be given a candidate CIP number.

[coot]

Thank you @rphair; I won't be able to attend it today, but I can join next week.

[Crypto2099]

There are still a few lingering questions that I have and recommendations that I would like to see completed prior to adopting this into Proposed status and merging.

[rphair]

@coot - in addition to the document nitpicks of my #1033 (review) we have @Crypto2099's more substantial questions about versioning & updates in #1033 (review) that will need to be accommodated or discounted before merging.

I think it's OK to keep this at Last Check in case all the latter issues can be addressed tomorrow or early the day after: but we will have to either assure this before merging or put back to Confirmed status to allow more time for these perhaps substantial changes (particularly the suggested enhancement of a JSON database as per #1033 (comment)).

[rphair]

Putting back to Confirmed status as per #1033 (comment) since the meeting will be starting in a few minutes without the above editorial comments being addressed... which therefore we would be doing at the meeting anyway. @coot we look forward to resolving the above review points & getting this back into pre-merge status soon.

[coot]

I pushed some changes requested by the reviewers.

[rphair]

Thanks @coot for the last round of commits which, as far as I can tell, have addressed all the editorial reservations so far except:

• (checklist of implementations in Path to Active) #1033 (comment)
• (more detailed versioning may be needed) #1033 (comment)
• (ticking boxes for current implementations) #1033 (comment)

Since I think some issues above are optional (not required for the initial merge of the document - p.s. adding other issues that come up) I'm approving this and tagging it for Last Check: anticipating these 2 issues might be resolved before the meeting or dismissed at the meeting (@coot you are welcome to join us as always, especially if not getting any other editor approvals before then): https://hackmd.io/@cip-editors/117

[rphair]

@coot it seems a minor rearrangement of Path to Active is in order based on your #1033 (comment): what do you think? ...

[Crypto2099]

Seems all of mine and other's feedback and concerns have been addressed with latest revisions, see no reason not to merge this and progress it to Pending status pending integration and acceptance by the teams mentioned in the acceptance criteria.

[rphair]

FYI @coot our next CIP meeting where we had hoped to merge this (https://hackmd.io/@cip-editors/117) has been postponed from tomorrow until 19 August due to mass attendance at Rare Evo. If you need this to be merged for practical reasons please say so and perhaps @Ryun1 @perturbing can OK this for merge before that meeting.

[coot]

On the 19th of August I am on Holidays 🎉

[rphair]

OK @coot, given the lack of urgent objection by @Ryun1 and @perturbing, with affirmation by @Crypto2099 whose skills as an operations reviewer I have complete confidence in, I'll merge this considering the time delay we would suffer by waiting to do it in person. Your comments above make it clear to the editors that any updates to the details would come in completely & promptly through future PR's. 😎