Rust implementation status

Vladimir Matveev dpx.infinity at
Wed Mar 15 17:51:15 CET 2017

В Ср, 15/03/2017 в 08:59 -0700, Jason A. Donenfeld пишет:
> On Tue, Mar 14, 2017 at 3:11 AM, Vladimir Matveev
> <dpx.infinity at> wrote:
> > I see. I think that joining efforts would be nice, but, if I
> > understand
> > it correctly, that project is intended to provide a different
> > interface, using WG as an underlying protocol. I personally think
> > that
> > it would be better to separate these layers, providing the
> > connectivity
> > daemon and higher-level features separately. I may be wrong though,
> > it
> > is quite possible that the combined approach will be more useful.
> The objective of all wireguard implementations is to provide a simple
> and uniform interface. Unity is very important. I have no interest
> debating that point further. It is a stated project goal and a core
> design consideration that drives discussion on this list forward.

Sorry, I don't understand what exactly wrong with my statement here; if
anything, I do agree with the goal of making Wireguard implementations
as slim as possible (i.e. following the guideline on https://www.wiregu My thoughts in this paragraph were about the
implementation here:, which, on the
first glance (and I may be wrong here, too) appeared to provide a much
more complex interface than the one declared in https://www.wireguard.i
o/xplatform/. And my point was that it is probably better to have
something simpler, on top of which a more complex interface could be
built by someone else. This was not even related to the way the
*official* Wireguard implementation should be done.

> > This is understandable, I think. But still, maybe doing development
> > on
> > Github and publishing the contents of the repository there to the
> > main
> > repository is possible? I believe that taking advantage of the
> > issue
> > tracker and the pull requests system there would be very useful and
> > convenient.
> The main repository is on, but if people want to use
> PRs
> and issues, and Sascha wants to review those, then that's of course
> fine. Use whatever tools necessary. The important aspect is that the
> canonical location for all WireGuard projects remains the same.

Yes, I do agree with this, and I saw your answer on Github already and
I'm really glad that you are not against this approach.

> > I'm pretty sure that when WG get popuar, differences in behavior
> > will
> > be unavoidable.
> You are so very wrong. If you start with this stupidity, sure, you'll
> get brokenness. But if you actually attempt to carry out something
> worthwhile, then each and every such difference will be squashed and
> unified. I certainly intend to toil away to achieve this goal.

If you mean official implementations, sure, I totally agree, and I
agree that it is right. I was talking about unofficial implementations
- I don't believe it is possible to force someone not to create a
Wireguard implementation with a different interface, if they do decide
to do so.

> By the way, are you actually intending to contribute anything here,
> or
> are you just on this list to bikeshed about procedural issues?

I'm very sorry if I said something which made you think so. I totally
do not intend to discuss any procedural issues, I do not have a right
to do so and I don't think I'm really competent. If I recall correctly,
the only thing I said about procedures is that doing development on
Github (in the sense of accepting PRs and tracking issues there) would
be benefitting for the Rust implementation of Wireguard. I really like
Wireguard, and I also like Rust, so I do want to participate in the
development of the Rust implementation of it to the best of my ability
to do so. Again, I'm sorry if I made a wrong impression here.

More information about the WireGuard mailing list