TS impl

[decentralgabe]

So far:

• structure
• did creation
• key generation
• compression
• tests
• dht publish and read / en/decoding to DID documents

[kirahsapong]

nice!! some comments or q's, prob mostly nits

[socket-security]

New dependencies detected. Learn more about Socket for GitHub ↗︎

Packages	Version	New capabilities	Transitives	Size	Publisher
bittorrent-dht-sodium	1.2.0	network, shell, environment	+2	3.39 MB	emilbayes
z32	1.0.1	None	+1	36.8 kB	mafintosh
@types/b4a	1.6.1	None	+1	3.93 MB	types
chai-as-promised	7.1.1	None	+8	948 kB	domenic
c8	8.0.1	filesystem, environment	+61	2.12 MB	oss-bot
@web5/dids	0.2.0	network, environment	+44	23 MB	frankhinek
b4a	1.6.4	None	+0	27.6 kB	kasperisager
@web5/crypto	0.2.0	environment	+21	13.6 MB	frankhinek
brotli-compress	1.3.3	None	+2	8.88 MB	kyr0
rimraf	5.0.5	filesystem, shell, environment	+34	3.49 MB	isaacs
@types/mocha	10.0.2	None	+0	96.3 kB	types
mocha	10.2.0	filesystem, environment	+77	5.16 MB	juergba
bittorrent-dht	11.0.5	environment	+20	422 kB	webtorrent-bot
@typescript-eslint/eslint-plugin	6.7.4	eval, filesystem, environment	+126	56.4 MB	jameshenry
@typescript-eslint/parser	6.7.4	eval, filesystem, environment	+121	53.5 MB	jameshenry
chai	4.3.10	environment	+7	921 kB	keithamus
eslint-plugin-mocha	10.2.0	eval, filesystem, environment	+101	11.9 MB	lo1tuma
typescript	5.2.2	filesystem	+0	40.6 MB	typescript-bot
eslint	8.50.0	eval, filesystem, environment	+97	10.6 MB	eslintbot

[michaelneale]

exciting to see!

[Nuhvi]

Not sticking to DNS packet codec is a mistake. You should take my word for it because the codec you are using is already what I started with and moved from[1].

DIDs are awful anyway, but if you have to do it, put in a TXT record[2], giving up on DNS semantics for DIDs is just as unwise as all the time and money spent on ION despite my repeated advice against it.

[1] Nuhvi/pkarr@4fd7e71
[2] https://gist.github.com/Nuhvi/443b7dc066b6f5e9236adfb99b241939

[Nuhvi]

We know for a fact that domains are useful and pretty much the closest thing to a source of sovereignty in the web architecture, taking it to the next level with TLDs that are self-issued and censorship-resistant is useful regardless of what data you put in it.

From TTLs, to the wide support in every browser and operating system to the fact that DNS Packets simply do "service endpoints" better with A, AAAA, and CNAME, and that is infinitely more supported than DIDs, it is irresponsible to consciously decide to forgo all of that for no reason other than NIH, especially when the NIH is one of the pillars of the Internet!

[mistermoe]

@decentralgabe pushed a commit that does a bit of housekeeping and added a github workflow to run tests.

a few questions before reviewing the code itself:

• would it make more sense to add this to the @web5/dids package? that's where our js implementations of did:key and did:ion currently live and where we plan to introduce additional did method support (e.g. did:jwk, did:mic). Also it'd ensure that the implementation works with the rest of our pre-existing web5 functionality
• what runtimes are you initially targeting? just node? node and browser? node, browser, and react native?

[decentralgabe]

@Nuhvi our starting point doesn't exclude the possibility of moving to DNS semantics, just we won't get much benefit from them out of the gate.

Closing this in favor of moving to web5-js.

[Nuhvi]

@decentralgabe A big benefit you will get out of the gate, is using Pkarr's implementations in JS and in Rust, and knowing that they follow best practices and have a certain performance profile.

You are betting that implementing a good DHT client is easier and faster than conforming to DNS resource records.