<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/tor-hscrypto/tests, branch arti-v1.3.0</title>
<subtitle>mirror of https://gitlab.torproject.org/tpo/core/arti
</subtitle>
<id>http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.0</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.0'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2024-10-09T16:04:35Z</updated>
<entry>
<title>tor-hspow: Big refactor, dissolve this crate</title>
<updated>2024-10-09T16:04:35Z</updated>
<author>
<name>Wesley Aptekar-Cassels</name>
<email>me@wesleyac.com</email>
</author>
<published>2024-09-30T18:50:16Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=5d878d3cc068572d3c14e478051ecc2361ef26b4'/>
<id>urn:sha1:5d878d3cc068572d3c14e478051ecc2361ef26b4</id>
<content type='text'>
My previous strategy here was to try and centralize hspow in one crate,
writing it like a self-contained feature. That introduced friction in
the data types, prompting the use of simplistic types at the netdoc/cell
layers and full-featured types in the optional modules.

This changes tactics, dissolving the low-level parts of tor-hspow into
tor-hscrypto and the high-level parts into hsclient/hsservice. Full
featured types are used everywhere now, but the tradeoff is that
compile-time configurability is a lot more pervasive. Anything that
knows about PoW types at all needs to be fully configured out. I took
this opportunity to try a more complete set of crate features, allowing
users to configure individual PoW schemes.

Co-authored-by: Micah Elizabeth Scott &lt;beth@torproject.org&gt;
</content>
</entry>
</feed>
