Last Tuesday's conversation was very productive, a lot of people participated and many topics were raised. I'll try to do a summary of what was discussed there, please correct me if I'm wrong or I miss something I had some audio issues during the meeting and I miss some pieces, I'm pretty sure I will miss or confuse something important here.

We agreed on not putting much effort on multiprocess IPC (or an evolution of the current pt-spec), and focus or energies on designing the future of PTs as libraries integrated into arti. Having a clear API/ABI will be possible in the future to create an IPC if needed, as a plugin that converts the API into the IPC protocol, but that is something we don't plan to focus on in the near future.

We see a future where arti comes with "batteries included", so it has PTs and Connect Assist integrated and implementors using it don't need to do all the work of joining those pieces. There was many questions on how an API/ABI should look like for this. We acknowledge that in the past we've tried to be generic and reusable by other projects, but in reality our pt-spec hasn't being used much outside the Tor ecosystem. And we think it makes more sense to focus on what we need at Tor and not into making it reusable.

There is a big ecosystem of projects currently using PTs with Tor, we do need to include them into this conversation so our design doesn't miss key features that are needed by others.

Alex will prepare a draft proposal in a pad to start working and move this conversation forward.

Quoting meskio (2023-10-16 12:31:43)

Looks like the best date for most of the people is:

Tuesday October 17 at 1500UTC (tomorrow)

Let's meet in BBB at: https://tor.meet.coop/mes-gsp-tmh-2hm

Quoting meskio (2023-10-12 12:55:12)

...

During last week's meeting we had a conversation on the future of Pluggable Transports. Our current pt protocol[0] have many limitations, the two main ones are:

• We have to do hacks to do things like passing arguments, and they come with many problems[1]
• There are not many SOCKS server implementations and many PTs end up needing to implement their own (goptlib and proteus have done it)

We have being wondering if making a change from SOCKS to a HTTP based protocol is the solution we need[2].

For mobile phones we will need PTs to be implemented as libraries, and some projects like IPtProxy[3] have being created to work around that limitation. It looks like we will want anyway a future were arti has PT plugins and PTs are integrated in arti. We might want to extend that idea to implement all the connect assist workflow there, so clients that use arti don't need to implement all the logic themselves again and again.

With that future of PTs as plugins. Do we still need a inter-process PT protocol? and need to make a new version of the pt-spec[0]? Or should we ditch it and start working on what will that plugin API/ABI look like and how PTs will be integrated there?

It looks like this conversation doesn't fit well in our irc weekly meetings, let's have a voice meeting to discuss this. I have created a poll to see what date next week will work better for all of us: https://www.systemli.org/poll/#/poll/YRRF8K19Bq/participation?encryptionKey=...

[0] https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/pt-spec.txt [1] https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/104 [2] https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/130 [3] https://github.com/tladesignz/IPtProxy