[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] [gnu-prog-discuss] MediaGoblin, now an official
Luke Kenneth Casson Leighton
Re: [GNUnet-developers] [gnu-prog-discuss] MediaGoblin, now an official GNU project :)
Tue, 9 Aug 2011 19:40:03 +0100
On Tue, Aug 9, 2011 at 7:03 PM, Christopher Allan Webber
> I've looked at GNUNet before, and it looks interesting! I'm not sure
> it's compatible with MediaGoblin, except for possibly as a storage
> backend though, or unless there's some sort of tunneling system built
> into GNUNet.
there is. there's an IPv6 VPN plugin. on top of that, you then need
adhcpd (and probably the babel routing daemon) and some other stuff
that's designed to provide large self-configuring mesh networks.
funnily enough, these are debian packages [which i didn't know about
since i last looked at the babel routing daemon].
> As you noted, we're using OStatus. In regard to "firewall busting" and
> the like, I don't really know. If we were living in an IPv6-everywhere
> world, I think this wouldn't be an issue.
... but we're not, therefore we're buggered... except by having
gnunet's IPv6 VPN (which should be regarded as a massive temporary
hack), that would do the job.
> Regardless, OStatus is a set
> of web-oriented protocols that are, well, designed to run on the world
> wide web.
yeah :) it's a different part of the picture. a rather large one.
> GNUNet looks like it's its own kind of protocol, so not sure
> how compatible that really is. But again, I don't really know. :)
well, you _could_ modify MediaGoblin to be a gnunet plugin. that
would give you anonymity and routing etc. automatically. then, the
names of all MediaGoblin servers would be identified, instead of by
DNS name, by GNUNET-BLOODY-LONG-64-BIT-HEX-DIGIT-NAME. and if you
were to use OStatus, that would probably need to be dropped into the
OStatus server identification field in the same way. in other words,
instead of utilising socket, listen, accept and inetaddr you use
gnunet's equivalents. it's not precisely a drop-in replacement,
but... yeah ok. i know.
but yes, the temporary "hack" is to get gnunet IPv6 VPN
up-and-running, and the above
can just be "do it as peer-to-peer services with big DHT hacks on
oh, btw: yes, gnunet has a built-in DHT service, so in many ways it
would be preferable to write the required code starting with gnunet
right from the start.
(also btw: insert alternative infrastructure into above, named gnunet
for convenience because it happens to be the closest thing yet found
which fulfils the requirements: I2P might do the job equally as well
except it's shit, because it's written in java)
> I'm not really part of the design process of OStatus either. In fact,
> OStatus itself is kindof a meta-standard... a standard that just wraps a
> bunch of other good standards. The reason for OStatus altogether here is
> interoperability between services. Honestly, if I went with the
> technology I *really liked* on the backend, federation would be done via
ahh yehh, the lovely ex emmelly fad which should have been smacked
into oblivion before it was allowed to infest the internet and
people's miiinds... *sigh*. yes, although XML is massively verbose,
the fact that XMPP has a wide following and RFC IETF standards behind
it makes it a good candidate.
> But! Looking at the GNUNet VPN site, it does look like this is a sort
> of tunneling.
> In that case, if the web can run through GNUNet and act
> just like it appears to be the web in general, sure, I don't see why it
> couldn't be compatible. :)
well in ISO Stack terms, gnunet can be made to appear to be Layer 2
(if you use the VPN plugin).
then on top of that, you run adhcpd (and that babel routing daemon)
and that gives you a good Layer 3.
at that point you just don't care: you have a complete transparent
IPv6 mesh network.
but, for _best_ results, its infrastructure should really be
integrated *into the application*, at Layers 4 and above, by stripping
out all use of select, listen, send, recv etc and replacing them with
the gnunet equivalents.
then you have the advantage that the service (MediaGoblin, other)
doesn't by mistake end up leaking information onto the public internet
(by accidentally binding to a local IPv4 address), and the service
also has access to gnunet's DHT system. and more.
> I wonder how similar this is to miredo,
miredo: IPv6 tunneling client/server. i would be very very surprised
if it provided anonymity, friends-only networking etc. etc. i believe
it's designed for a completely different job.
i suspect - without enquiring too closely - that it would be
susceptible to attacks, being dependent on server infrastructure.
> Thanks for your enthusiastic response to the project!