Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Vladimir Matveev <dpx.infinity@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Rust implementation status
Date: Wed, 15 Mar 2017 20:51:15 +0400	[thread overview]
Message-ID: <1489596675.18476.2.camel@gmail.com> (raw)
In-Reply-To: <CAHmME9oaJA6xTwATpc0q=h9NO_F=ae-NveccSQpw-M4i-cF5Sw@mail.gmail.com>

В Ср, 15/03/2017 в 08:59 -0700, Jason A. Donenfeld пишет:
> On Tue, Mar 14, 2017 at 3:11 AM, Vladimir Matveev
> <dpx.infinity@gmail.com> 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
ard.io/xplatform/). My thoughts in this paragraph were about the
implementation here: https://github.com/sopium/titun, 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 git.zx2c4.com, 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.

  reply	other threads:[~2017-03-15 16:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-05 11:42 Sascha Grunert
2017-03-12 23:09 ` Vladimir Matveev
2017-03-13 16:58   ` Sascha Grunert
2017-03-14 10:11     ` Vladimir Matveev
2017-03-15 15:59       ` Jason A. Donenfeld
2017-03-15 16:51         ` Vladimir Matveev [this message]
2017-03-15 17:03           ` Jason A. Donenfeld
2017-03-13  7:04 ` sopium
     [not found]   ` <CAHmME9oFbpNBTszO_Q5m8EwiG0F0SH6BUd+1SFZGUDGH0wQ0gg@mail.gmail.com>
2017-03-13 14:39     ` Jason A. Donenfeld
2017-03-14 13:08       ` sopium
2017-03-14 16:29 ` sopium
2017-03-14 18:49   ` Sascha Grunert
2017-03-18 10:51     ` Sascha Grunert
2017-03-13 17:00 Sascha Grunert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1489596675.18476.2.camel@gmail.com \
    --to=dpx.infinity@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).