<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/tor-proto/src/client/circuit, branch arti-v1.5.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.5.0</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.5.0'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2025-08-28T10:54:48Z</updated>
<entry>
<title>proto: Add a circuit module shared between client and relay impls.</title>
<updated>2025-08-28T10:54:48Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2025-08-26T17:48:56Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=4ee5a4abcee895e79588888f6bc8eaa6963a6ba7'/>
<id>urn:sha1:4ee5a4abcee895e79588888f6bc8eaa6963a6ba7</id>
<content type='text'>
This is just code motion (I suggest reviewing with `--color-moved`).

This also moves the implementation-agnostic parts from
`tor_proto::client::circuit` to a new `tor_proto::circuit` module.
</content>
</entry>
<entry>
<title>proto: Avoid referring to restricted ChanMsgs as "subclasses".</title>
<updated>2025-08-28T09:08:17Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2025-08-27T18:57:16Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=997b56b9fe7daed11c80467ed453738811ca0996'/>
<id>urn:sha1:997b56b9fe7daed11c80467ed453738811ca0996</id>
<content type='text'>
</content>
</entry>
<entry>
<title>proto: Add a new RelayCircChanMsg message subclass.</title>
<updated>2025-08-28T09:08:17Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2025-08-27T17:31:56Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=c23549f6b76ea19dc41ea65f5d7ef2d4af39ac78'/>
<id>urn:sha1:c23549f6b76ea19dc41ea65f5d7ef2d4af39ac78</id>
<content type='text'>
This will be used to restrict the types of messages that can be sent on
the relay-specific channels.
</content>
</entry>
<entry>
<title>proto: Derive ChanMsgSubclass for CreateResponse, ClientCircChanMsg.</title>
<updated>2025-08-27T18:08:57Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2025-08-27T17:46:38Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=5480ad5eccaafff2deb329cf679e54692ded9a1a'/>
<id>urn:sha1:5480ad5eccaafff2deb329cf679e54692ded9a1a</id>
<content type='text'>
This enables us to remove the open-coded implementations in favor of the
derived version.
</content>
</entry>
<entry>
<title>proto: Add d-d macro for creating AnyChanMsg subclasses.</title>
<updated>2025-08-27T18:08:57Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2025-08-27T17:43:02Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=09706993c7c76ebb4d82db475210d53cfc5fd179'/>
<id>urn:sha1:09706993c7c76ebb4d82db475210d53cfc5fd179</id>
<content type='text'>
The code for generating these is repetitive (see `CreateResponse` and
`ClientChanMsg`), and we will soon need a `RelayChanMsg` type too, so
now is a good time to introduce a helper for generating the boilerplate.
</content>
</entry>
<entry>
<title>proto: Rename the `tunnel` module to `client`.</title>
<updated>2025-08-18T16:09:04Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2025-08-18T15:14:43Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=1ee26f2168ee2dede8ab993ef57435334e9efabe'/>
<id>urn:sha1:1ee26f2168ee2dede8ab993ef57435334e9efabe</id>
<content type='text'>
The implementation from `tunnel` is client-specific, so we are renaming
the module accordingly. The more generic parts will be pulled into a
separate module in a future commit.
</content>
</entry>
</feed>
