v0.6b wishlist.

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One last ISC development grant milestone remains: The writeup. It's
going to be a lot easier than the other goals, so I'm not going to
belabor that point overmuch.

We should start brainstorming new things to add for v0.6b, which isn't
yet on deck but on the roadmap. Let's start throwing ideas into this
thread to see what we can come up with.

Personally, I'd like to add opportunistic IPsec to Byzantium Linux, to
encrypt all network traffic passing between mesh nodes and not just
whatever happens to already be encrypted with SSL or TLS. It's doable
but not many people actually do it, so that's probably going to be a
separate development project.

The database abstraction layer of Etherpad-Lite
(https://github.com/Pita/ueberDB) now supports more databases than it
did a few releases ago, notable among them Redis, and CouchDB. I
mention these two key/value databases becuase they're extremely
amenable to ad-hoc replication of data across networks. CouchDB makes
it incredibly easy to do (you just have to hit the right RESTful API
with a couple of IP addresses to make the datastores replicate to
other nodes) but it's written in Erlang. While Erlang's not a bad
thing it is fairly large and would add a significant amount of size to
Byzantium Linux. Redis (http://redis.io/), on the other hand, is much
smaller, written in C, and has both a master/slave replication system
and a PubSub replication system which I think could be leveraged to
replicate Etherpad-Lite documents (and any webapps written in node.js
that use ueberDB) across arbitrary numbers of nodes.

We also keep talking about finding an IRC server daemon that we can
use to set up ad-hoc IRC nets without having to kick everyone off a
server when it restarts (to join servers to the network). Haxwithaxe,
you're more up on this than I am, would you take it away from here?

- --
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

"It is the mark of an educated mind to be able to entertain a thought
without accepting it." --Aristotle

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHuxskACgkQO9j/K4B7F8E+1QCgvRp0l68psG+aASYtsMKEJhWn
FWsAmgMEULDwTHSSo3gTpVQWlgaIIHaQ
=Aq7Y
-----END PGP SIGNATURE-----

[richo]

On 23/07/13 14:09 -0400, The Doctor wrote:
>We also keep talking about finding an IRC server daemon that we can
>use to set up ad-hoc IRC nets without having to kick everyone off a
>server when it restarts (to join servers to the network). Haxwithaxe,
>you're more up on this than I am, would you take it away from here?
>

>--
>The Doctor [412/724/301/703] [ZS]
>Developer, Project Byzantium: http://project-byzantium.org/
>

I think you're going to have issues with this.

IRC just doesn't respond nicely to this kind of federation, you either have
to choose to elect stable-looking faux-master nodes and deal with the
inevtiable netsplits when they happen, or make every node a "server" at
connect time, link them as best you can with the traditional leaf-stem
structure, andtry to insulate clients from netsplits at the irc-client level
by letting the server try to renegotiate on their behalf, but take a massive
hit on network bandwidth as a result, or try to implement some custom
peer-handover extension to IRC (and bundle an irc client that knows something
about it).

That last part sounds interesting to me, but I do wonder about IRC's
suitability as a protocol for something like this, it was basically built
from the ground up on the assumption of known-good sources of truth.

That said, I spoke to a bunch of really interesting dudes at noisebridge the
other weekend, and one of them gave me an idea for an ephemeral ring-routed
protocol for non-persistent data, which might be possible to flesh out into a
chat application.

I'm still really time poor, but I thought I'd put that out there as at least
a conversation starter.

richo

--
richo || Today's excuse:

The Dilithium Crystals need to be rotated.
http://blog.psych0tik.net

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/23/2013 02:21 PM, richo wrote:

> That last part sounds interesting to me, but I do wonder about
> IRC's suitability as a protocol for something like this, it was
> basically built from the ground up on the assumption of known-good
> sources of truth.

That was my concern as well. When a mesh hits critical mass,
netsplits are going to be a serious problem for a couple of hours as
more and more nodes appear in the network. That's going to drive a
lot of people away.

> That said, I spoke to a bunch of really interesting dudes at
> noisebridge the other weekend, and one of them gave me an idea for
> an ephemeral ring-routed protocol for non-persistent data, which
> might be possible to flesh out into a chat application.

Interesting! Do you have any details on this protocol, or is it still
in the planning stage?

- --

The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

Your memories are fiction.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHu514ACgkQO9j/K4B7F8GVxgCgiP4uPoiYeabgtPsDaVLqYnT4
lFMAoNFillF9kb9UQfPALm+++wglggb5
=tiJi
-----END PGP SIGNATURE-----

[richo]

On 23/07/13 16:28 -0400, The Doctor wrote:
>On 07/23/2013 02:21 PM, richo wrote:
>
>> That last part sounds interesting to me, but I do wonder about
>> IRC's suitability as a protocol for something like this, it was
>> basically built from the ground up on the assumption of known-good
>> sources of truth.
>
>That was my concern as well. When a mesh hits critical mass,
>netsplits are going to be a serious problem for a couple of hours as
>more and more nodes appear in the network. That's going to drive a
>lot of people away.
>
>> That said, I spoke to a bunch of really interesting dudes at
>> noisebridge the other weekend, and one of them gave me an idea for
>> an ephemeral ring-routed protocol for non-persistent data, which
>> might be possible to flesh out into a chat application.
>
>Interesting! Do you have any details on this protocol, or is it still
>in the planning stage?
>

Not really. I was thinking about trying to flesh it out based on something
like telehash. Essentially construct a big content addressible directed
knowledge graph (groundstation..) but with a focus on it's ephemeral nature.

Instead of focusing on a strict decoupling of access and syncronisation,
deliberately intermingle them to expose the reliability of data to clients,
and have a "more like this" style api to reach out to the mesh to get more
data.

I'd like to build it "mesh aware" from the groundup.

I'm in two minds about the idea, either building it on top of groundstation
(Interop with peer discovery code, transport layer and the GS socket magic,
and maybe the same protobuf mechanism for request encapsulation) but it'd
need a very different datastore to git's odb to be feasible in the longterm.

ACTUALLY. Ok, now totally at the edge of what's sane or reasonable, but this
guy in melbourne was trying to sell me on the idea of an inmemory gitodb,
basically expiring objects in response to memory pressure (fixed allocation
at boot time, although no reason you couldn't balloon).

Obviously this is still at the "back of the envelope idea" stage, but it
sounds fun. I ight see if I can flesh something out, I've got a few days
pretty much dedicated to hacking by a pool on my defcon trip.

Feedback/questions/criticism obviously very welcome.

--
richo || Today's excuse:

hardware stress fractures
http://blog.psych0tik.net

[Brian Makin]

I was toying with the idea of using bittorrent with distributed hashes to create an IRC like program.  Message delivery wouldn't be guaranteed... but in meshes that is generally not a problem.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJR7ukiAAoJEIKiWz6J5yQV/qIH/3YCjGKYfPjEp2Bxquapd//M
Xr+MjioNUPVelGEW+4K/VGoqJuJiQjqJ9RbVU3avqRfMF9qeHLlGs3+S+8acjErN
peUkxTPuPapLcVGSi/Rw2S1a+0u6DvQsMwCKCbuTUtEqTd0Gcq0jgom0vAQ1IJ2R
4brMPAOLJwB5Vs0Vzbp3oZQDKQ2Jl2Xcb3EEAjS6FLLzYwvAO4svyL7d1fbf5+Fq
x3nfv9dUQgt61foviOxWwmrQ/nXgnHeK4+Wjdon+ZvDaokKpHGnAbRqrzSqwNny5
U0uepmvalwAnfdLgauOZWf+owttSoxa9ET8PJNdAUhs+nDQ+uwFlIe8xcWhxT/Y=
=FYax
-----END PGP SIGNATURE-----

[Dean Hall]

-----BEGIN PGP MESSAGE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)

hQMOA/mFjeQRLlHdEAv9FJS9bv99cNXWVmeqrihNTYP8wCEmUKMb828diPG+WR3G
qPfTPiCaeb/jA+oeQym6PHRmzJrzosDujPkaUCvy+mjPrQ7+nUEg32zqegfoeAFN
Bo+O5owyS/p2kfiOgYGvGiaXyLrbXGD780PTc/rlHL84m1Soo3y1vzTwqSDTthf4
jmSmaFlRlGCZq8tU4Fu2dCLfaDgttWzfUz0fLGAWIPO0K8VqAH2F7a9woo8ZDhaP
gUNrjTJiI14XxejZVVr4wWnT6beiCGqGNODvc8MC/GP3Luu8qnT1Cufu757ebxV0
Dlx9b3I+NcBHi1TLDB2GSsanMXcH6eVnZznQLNsfaTgyhKmrnKkN3sVgg3l4gcKf
YtSPNZ2rKJVN4JZaOTcxg8VEMvfrHF0l2Ukgl+66uFqGUFxpy4c4bxSC9/GBGOX5
lJbYzipcj+ra9cuVXiF1Y5IkiZan/Os5BeNyFV7nZxX9YADt68dEtDFqzv7CQbS7
Udpd8duLG/78oMC6UfBJC/4mBqEj6n0RaqTYbKXhkgbM/DlE3JDivYbloBH/pwDx
DqIeKBAvBdL7oIXayXZ1TjBIGrCgtoLp5UvnhpHcMAcyebOsMb5DHCA+yGJumTTR
3VzcX4d9cb9D8yWKS9HgbWjxJBI93EoTcWyLUc7PPTI28ZIl0pTX/dw6HSyCgBhl
kQtO+n79/gqVFu+kJ2S8Ew4jjyN98QI2q8RhDDhMvqFLNo2RqYjNEMAshYUVmrHR
LbLfZBZK1TFKet9t3X8Dy5NPJKWWradRsQ6CnyaOeu7VgStl62wS/fcSWXDJmZVC
8P1Ccml/viXtr8kHpN2I1mnS/4hXss1IKbh7kRfGEi+I3JnwWBLg4QReTql8Wg1u
9jO2rMGXDz7i+emxcrorJoYt+Ktr7SK59GgkZ42PO6vVGx4Q/A27eDbUr4UvxARf
zavOQWQUwhW/xNxJL/+xsYgooJ024F0rWlt5axXuHER3quHJAsHzKCM0kTH9lq8A
druwunDSATShDbkCPtXG+HCFAQwDTKIKh1FGbbwBCADQtImp9AnvTX8T3tzK6lyV
wZ9VeU9xeqmmzcVVm64W9Xl+6cDDwh2jQN+HCbr5qD4GMhsnW7/bO2ia0P8P0bhg
h2LciHUTIuMssesLovc0U9bs/PkkWaon2Amr7y150BKarr0rZuxD2SfSNxU2yXBR
5arUgLX3dFFt4xsM8YSWt3hTQpUy9x6AcFk49LTEgAxjgFBzafmasijgAhe5wOPz
tsPnxy82wlJ+EeNScsaRs3saX6YlVYKlN7ZNm9DwuO21Gvrb8SadA7HQVBhhTytE
NKkaVSr0L0zu2cuZ+wQRV3bWzMsMcA9r0X6Rn9dUKhQEccL4Oo+3LK4Ks5Qo4Qpv
0ukBCpL9XLU8/PODUhIFUP7moxf/15yY5neMNQ0I2PPqKDbWxqP8tPSRRMUrVZRk
ftbh13QPbxg733MtrjVTGkxoEoF/L40yUYI4ceoR1iZGl/Bip5oN/A1pgFh4ZB8n
5g2S3gF38q8hFTDg5fiSbl0y58w/GtwjblkwtJIYXsqlZCDJAN3ZO4KEpKXhPlp2
nV555c+ihVDgCOj21uHxNd1TEcZcfcYDVdFfMrOQQUX4jfIeMxK3+BjVWVOtfR+M
8OZvVrby3F6JO/hX33s4R3DL6gAlLDI1Kw7Dg0i3LuuvCLCTBhq7WZzvHGQg86F2
MAt+A7A+hZwBTZyHaYq5Y7KgbhJh02f6tF1OKV8MztD42Rf9cRy/G94soXMGV2Ax
gYSLpzZANJoyzsI+rLy1J2g8mcCMB1z1AXVNKkt2AArV2x47RjyHTsTjJbSHTx4/
hmTYuRV5apMqm0CFzD2x1T0pwAxsS7OduB82/gevCKOPr12lMvn+nIcI4ivhNel2
0RWWPaFOxAQlJS7NapnKHN0eT3rJAjCNlBBvazFs7APoqu56A7+eG+NxuWkrgE6t
5Y3wITpEnT69je1WXBh5pCMLZE4QWi/MAycVR8/w2K8tinZXO9BUGL6a8Cq9ZAkU
WPJrsabMdZ/fZ1yx4D/SwMKVqCxydcPi81ZoDtPO5I0e+6lYsvhdmSPIuGQlIVIC
mU9CP1So6YQxzuEtAZQHUOyQ3AtPv+kgjz3NAXApaXLCcY9dwg6yA/KoBePS0CcV
+hy07UMVraC1vxV3432cTrXE0Srj++zIiBtcdG7jVD0vp8HTNywpH9JS5H6h92q9
FI+k8NRaQgJW8pcNkNzlHEK5FzmuOpUl3knVNQ5zSYcsUX1tpqEKjSDD0QIUeiJN
SlObwwl0mFoawLhp
=ejLt
-----END PGP MESSAGE-----

[Dean Hall]

Sorry about that. Didn't see the checkbox until too late.

!!Dean

[The Doctor]

-----BEGIN PGP MESSAGE-----
Charset: ISO-8859-1

Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

hQMOA/mFjeQRLlHdEAv/SQQZVFBqkOa3EmfLW1Su7zlrTP60WE26lg0gU7gMZhVY
owz1376UPmVBboAu5Ymzv1HU0T9GderjEqyGIqskivRznkdn9yWkIt2AQbuNdaW7
4qdHlMN6VVeLoAHzYypcOI8hUbE2KSxf2l5YhIbEtHrYPnnEYt1wLUKKlq8SmO88
IRfxHZPEnnn6WOfX0NWnxFCHZG6P3Q0R21/ZFgAIklX2Nz9enTQSAAS1dzwjam8Y
pHPRCtpYsErtqix3zrsdnD90JsOoE2dDj5xmK7kZxoGJ4YoENpxpoSF0tWKWTj3p
FVq9J81eaOGlhudMOhra29smeHUiacGRBS7FaCa5BraIA0ZJQUi25ZQhaD1QR2Dv
fO/kQ0bugyP1AqgSUMKDhdXboV2CRbT9NntwttyBOic5Eq+D5/smaFIIqY9mR74W
ICBqjtiODMF9Tgd3oVShVFG44E7Hi5F+t1ku6eRKDoX+UqHjtFT+uSLWJ4/RxQ5+
7E44a/xQEO6syYxDdj8DDACVE2MndYXnsHIL6tWBPFo9DtqXichQ1176yeRKxMTN
cU+vXwJM/oJK+BTh+FfLri1exZXZ6vTsvbZI9NsmoWkqDBjFETzu+CK+3cnRzUIQ
cepfSVqXyYQ3n2uf/7/OYqCCoY9j2USYuAMbqsAebbnAnz7GYLtGU222kNWHp45R
z2V6dDe+1yUDEacwqLNdrGFBgLkM0o6LZyLjBdWD/TsHP1toF2K9L9FLYnNDu0QD
gWgy13A51aRiSk5bvnHEVZUDY/UoXtZXw9WItq+D+s163MAFmA17PuvlfkwMgMDW
JxQF1AI01f/L5K+qgG3jzvs6KNBrc1HsnbEEjbkjylnkDN2z0tv5maZe+uJN7pPQ
nOXjyb3laQdnHgyvv2Ql9mf+zgspGQ0r5jVEP+dMcmjkhyXG902l+2DoGVR0cJjc
A1cO7jnEjSJ++X18lRuWcVCc5OPrq/pDbVyXj2f8f4HoNQTCZgy6SaWq9ls8MyVZ
99laQWLN/rtHCshncg5JJq+FBA4DEjh1SVItH+YQD/9VgZnnWKcmSv2z57TyapHw
M7OabbnCQ1/0Fr1apz1jCei/Tk1u7YQL3fu/SFfefjJe6x2seYaNNkBLDJ81obgw
YY1fpOW/MT7uQ16RAflKaCIc8373LtPRT5YRIq2gDq+PipT8xU59+Cg4x5j1xhdq
XvrdAQuWCS2HxCiO0PD2VfFvnT957PK/VWvATjWUeyLYFdgr8srR8rxEMFqEJNyu
BQHLao5SM2zbUqgm6pVNaiBeX0EbqMO6I/UEiXBadnriEOKa0zPNfoZjO3AvkS/q
thPwaqPfSsnc1Lr1+2OEVq6OGXXnTPBmcfzN6LwKFaRVLX7kFDkpFiHTlnlqqLR5
USy2uWb5r31T9edch4TmnJJSo1tbnJwkm4BTY7NiL2LqNXQvek10stHVgMKDlk+6
KEUnKJ+ubfwopfZs+NX74RQCjomelAbPfXDzgGoowj4pD5MzeV3vnUdOsCPR4DkS
qSKu7TPsdMjECH4I3TmaFc1mRQrfS9DB1JpWk1fmt+TWhP+V1Fg4AfeHG7Lll/Zj
RrKJd+cVIksRftv2n28WHBCgCRvpWsmpccGy7S00CLLnGcydXLG6VOfsszVDVdfQ
9yAb6pGwRuvpYZVkV48UCT4PDfFGoYy4v3A3mWzzJfFCrCZbnoIP2tT4XvchSWzG
XJ0Z1ZOvoMn1NN2RqJ5oPQ//aZ4rP9IqUu//xMwNpwsj5h0UOXBC+TaQfsznfrtD
aMc7/J+s8uq0CuAwVukTHepMtskjByotoT9joYwMX6yQgjMgt0eEc53iLcbm4Eal
hE0ti25gnOisasjMEiP5qpWtTpecfTy1OhbH8t/9kGz6TTOtbUY+1CaSRDDDu++R
Y2nHVcr0U9eiM/RqUi8FvAYZd8PvUfUggoLgOt3/esJTbs6p1TOCln1mFzCbFRJK
I+peU2/0evWl74uZbD7TfklDpRYIV2nxvc9H0wS79YKhsIrYnt3FhTMljAOr4t2H
wnMt+pp3VPwKB8lIWf5t4wnaPsFG9DkB7qZJ8ryS9VN8TTATHGUL2aQ4yCx7dD3t
2zMYlxeVXBiIZNy+xppO4rsb+060nRYyB0aEDLzJHh+oSEyO6kWAQYoSyeQsiJmb
raC0wIIrPYffNyowIld74poYD2yO72L/rr2N+FG5cLvTZdSPXZGrfH/n8sxr1vmM
n1PqdbOHUmt1v8mKJ32kxsx6bKEcML3FS+oWv4U8mPcFlTAuLQ8HXBWfxjH3a8Lp
dz15Bz1C74nOSuAUdscW8bTgv+EbL5B1mBH1i4G9vjCwSQsIJ5Xmdlhbv49+cC7g
7Lbf2tja+vk2CFlnL9Fd6qWON2e/LPLlozts8hbMWWLalhDOZNJzUbwaUgjVd7Ty
m5XS6QEp1jTPj1pN/2d3hAx4/JDQkOyPAk24IKTH/NDC4mhEoJ+VmT9nS4V3qW1u
hfu5GmCSdz0IucpMlDfUcS0cAHGtrdqRRfloxQ9tgR1dABFscLSYXwN2KI68a7CH
du8xvZm0W51B9L3G8DuPCsgNUM94MVtOc5ojtzGC0b06tmhFrj7vQ+XaQvL9yPdM
yC0KfdTeWwIbFxS+L7ZKv9CIoB9t2xXfagoXlmnI2xOhLBalwG5HoMFLxsrJyMFb
Va9ndoxK6CnRzyL6IzqvHW5vxYwYnHYMAl8Kc5CyCzPP9DC92MUxDNOA8Odyranh
uJH8ykovULS8Sjx2JIVi2dmuUoq68CfJdbKp8/rh8NxpQUFAJzA6lqq25wX+6xo/
F5cXVs5lXGidtSONmsMkbzjJ+gr6/L5BBKmt16sdWsRwqp5likdmoaIIDs7sUtBo
cdXQAgLfGGhoZvWdbQ7ADaDxF/LvPZZy+tw0HMBOAQMk0xaxhlxL+gokMkgyL0xU
/RiAS5icX2I530IQ9MCFHIrbWuxSw/o/RCmYfsVZe/eEircgm3w+9z5wNKRtDPfC
sffefXupYaKFx9n61hcUXvZLSEYZjrr44vM4d+9OkxwjW2Mb6NT4IZB9lKXGoir1
IYYgXUclA9h+oQruX1DZaI9fLiJA21yQK8fUfZ4X9XPGh2HGwRDV/8zVjUE1+PUz
FQF9B19jhoes7ZEDATW5kA1PFc7Rpqaji9YaQZs8PB3gj2FBANJfLph6elus/E5g
HPD78wGE3E3U6E2y/qKa1lSswfyNN7zRkTU71Op9/Ef5DmAJubwsH7BoPANuBLuR
E5BXrwZEeSmCcsQ6fxkO4j3gVOcVFGXNGfcRc1e6Px6g55hGvYqiRmXFv+wbvb0d
ifGeDPzO0rut820a6k27yYnBWH22422hnUrK3/DhEvtDFOo5EgvYJyYfdbaVSlHq
F0i4ddlzsNMC+I3yGgmXBrHbRYIRId+S9J9sx3sJ1cf6VVVTSNmAIwJLM+KKDOMD
QQIel7grpnW413OcapbKGgUjDrOg8WvaTIQR50nYVRfasThzW6X0x2WFk/QoUWm+
u/cuky5zNlSyElXFC+88S1rM6j4e0BFFBmK8LgjdCMo9PNRtJ38TuXb00CYd/60+
vyQRfoON9zgt2nXFH/aIrpafe2lrjBQMjyYiGS9fTzRbhbwuKxWLsU7WiVMjg20m
1rD8cEJFa0sZvGiHuTC5f3IHAHeuEBN0vyrJnO2VTyA31Ars9gnRnEPCj100qiHq
6kEq77KOpVDXVmNgdSj6mLsfzMX9lQ==
=ak8N
-----END PGP MESSAGE-----

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/24/2013 10:37 AM, Dean Hall wrote:

Hi. You encrypted an e-mail to the public Byzantium list with our PGP
public key. Good work! Unfortunately, this is a public list so
encrypted e-mail is counterproductive in this particular use case.

EDIT: Wow, I fail hard.

> If just toying, I would think a dvcs would be a more appropriate
(though not
> ideal) off-the-shelf tool.

One of the things we were toying with was using Ikiwiki
(http://ikiwiki.info/) with Git as its back end configured as a forum
(like the TAILS Project used to - https://tails.boum.org/forum/). The
problem then is synching every node's Git repository as posts are added.
That's why we originally started exploring Groundstation, until we
discovered that it could just be used as the distributed forum by itself
(with a lot of Richo's help).

I don't know if it would work well for realtime chat. It's possible
that Groundstation is a good replacement for IRC in toto, but that's a
determination that has yet to be made.

- --
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

Real Daleks don't climb stairs, they level the building.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHv8IcACgkQO9j/K4B7F8G3vgCeJkx0N8RAMSa1ZYFjl68GLf4o
a58AoLNtMsVehgQo8c8oz2I3JsdCTSPY
=X3ZN
-----END PGP SIGNATURE-----

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/24/2013 10:34 AM, Brian Makin wrote:
> I was toying with the idea of using bittorrent with distributed
> hashes to create an IRC like program. Message delivery wouldn't
> be guaranteed... but in meshes that is generally not a problem.

One of the things we were experimenting with was an app called Litter
(https://github.com/ptony82/litter), which works like a cross between
IRC and Twitter, and uses UDP multicasting to broadcast messages
between clients. However, it's a single user app (like IM clients
tend to be).

Groundstation pretty much does what we wanted Litter to do for us,
plus we don't have to modify it so that one running instance of the
application can support multiple users simultaneously.

- --
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

Real Daleks don't climb stairs, they level the building.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHv8b0ACgkQO9j/K4B7F8EdWACeOIlbFBRwuNhckblteUyX54Fi
VpoAoLrXB126/dzadScyRadpdBxiQFy/
=pB4Q
-----END PGP SIGNATURE-----

[haxwithaxe]

imo a simple irc-like multicast based protocol would be best. it could
opperate like a normal irc client when chat members are online and stash
messages it know the recipients of (or anything it doesn't know is
online) and forward them as it sees the targets or sync them via an
alternate multicast network.

On 07/24/2013 11:24 AM, The Doctor wrote:
> On 07/24/2013 10:34 AM, Brian Makin wrote:
>> I was toying with the idea of using bittorrent with distributed
>> hashes to create an IRC like program. Message delivery wouldn't
>> be guaranteed... but in meshes that is generally not a problem.
>
> One of the things we were experimenting with was an app called Litter
> (https://github.com/ptony82/litter), which works like a cross between
> IRC and Twitter, and uses UDP multicasting to broadcast messages
> between clients. However, it's a single user app (like IM clients
> tend to be).
>
> Groundstation pretty much does what we wanted Litter to do for us,
> plus we don't have to modify it so that one running instance of the
> application can support multiple users simultaneously.
>
>

--

do you accept PGP encrypted messages?
https://en.wikipedia.org/wiki/Pretty_Good_Privacy
i accept encrypted messages!
encrypt all the things! https://www.encrypteverything.ca/

[richo]

On 27/07/13 02:19 -0400, haxwithaxe wrote:
>imo a simple irc-like multicast based protocol would be best. it could
>opperate like a normal irc client when chat members are online and stash
>messages it know the recipients of (or anything it doesn't know is
>online) and forward them as it sees the targets or sync them via an
>alternate multicast network.
>

Given a few days I more or less have a protocol specced out.

I want to reuse groundstations transport and peer discovery code (as well as
the interface to the transport verbs, basically so that if I do http2.0 for
one project the other gets it for free), but iwth ephemeral transit and
basically a ring buffer of "seen" messages.

I think it'll scale ok, the thing that'd break it is every peer talking to
every other peer for a large number of peers, but that more or less breaks
everything else anyway.

I hope to get some PoC code out the door around the same time as defcon, but
I'm totally open to collaboration. For clarity, reusing the code from
groundstation is purely because they're "solved problems" letting me focus on
this issue specifically. If there's something better suited, I'd rather use
that.


richo

--
richo || Today's excuse:

HTTPD Error 666 : BOFH was here
http://blog.psych0tik.net

[Mikael "MMN-o" Nordfeldth]

On 2013-07-27 08:19, haxwithaxe wrote:
> imo a simple irc-like multicast based protocol would be best. it could
> opperate like a normal irc client when chat members are online and stash
> messages it know the recipients of (or anything it doesn't know is
> online) and forward them as it sees the targets or sync them via an
> alternate multicast network.

I have a hard time seeing any system keeping track of whether a certain
user or unit is currently online, as it'd mean keeping track of openly
definable unique IDs. Unless some complex solution for a central
directory would be put in place.


Personally I'm a big fan of the XMPP-style link-local/avahi-based chat
protocol with many names: Salut, Bonjour, "People Nearby" etc. It uses
XMPP XEP-0174 "Serverless Messaging":
http://xmpp.org/extensions/xep-0174.html

All major IM clients (libpurple and telepathy based at least) support
it, though they might call it various names.

Unfortunately XEP-0174 doesn't support group-chat, but assuming one is
interested in putting the effort of designing a protocol for this - I
think it's a good idea to kickstart from this already existing protocol
base. .)


What XEP 0174 does is basically broadcast one's presence using UDP
multicasting, following the DNS-SD specs, and then establishing P2P
links for communication.

No central directory or anything, and DNS-SD can be forwarded within a
mesh. Commotion Wireless has a plugin for this bundled with their fork
of olsrd (in lib/dnssd):
https://github.com/opentechinstitute/olsrd


I haven't looked at Groundstation yet. Will go and do that tonight!

Cheers!

[haxwithaxe]

On 07/27/2013 04:10 AM, Mikael "MMN-o" Nordfeldth wrote:
> On 2013-07-27 08:19, haxwithaxe wrote:
>> imo a simple irc-like multicast based protocol would be best. it could
>> opperate like a normal irc client when chat members are online and stash
>> messages it know the recipients of (or anything it doesn't know is
>> online) and forward them as it sees the targets or sync them via an
>> alternate multicast network.
>
> I have a hard time seeing any system keeping track of whether a certain
> user or unit is currently online, as it'd mean keeping track of openly
> definable unique IDs. Unless some complex solution for a central
> directory would be put in place.

sorry, i wasn't exactly awake when i wrote that :P
you can have clients request messages for themselves or others when they
come online thus negating the need to keep track of other nodes' states.
you could have various types of buffers for the messages but a simple
rolling log of chat traffic would probably work well for periods of a
month or less and date/friend/neighbor based buffering could probably do
well for much longer time frames.

> What XEP 0174 does is basically broadcast one's presence using UDP
> multicasting, following the DNS-SD specs, and then establishing P2P
> links for communication.

that sounds nonconducive to a muc. the possibilities for a muc via this
seem to be peer to peer to peer chains or an all to all type arrangement.
the wonderful thing about multicast udp is that you basically get a muc
for free. anyone sending to the multicast address is heard by anyone
listening to it so it's already getting to everyone. to implement a one
on one chat over multicast you would just filter out the other messages
:P (or negotiate a nonmulticast connection)

> No central directory or anything, and DNS-SD can be forwarded within a
> mesh. Commotion Wireless has a plugin for this bundled with their fork
> of olsrd (in lib/dnssd):
> https://github.com/opentechinstitute/olsrd

we use dns-sd as well. our currently not quite working DNS workaround
uses avahi to advertise records for running services.

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/23/2013 01:35 PM, richo wrote:

> I'd like to build it "mesh aware" from the groundup.

I think that's going to be the only feasible way forward for a
distributed chat system. Repurposing IRC works.. kind of. A lot of
jiggery-pokery goes on behind the scenes.

> I'm in two minds about the idea, either building it on top of
> groundstation (Interop with peer discovery code, transport layer
> and the GS socket magic, and maybe the same protobuf mechanism for
> request encapsulation) but it'd need a very different datastore to
> git's odb to be feasible in the longterm.

This might be me re-using the hammer I have in hand at the moment
(because I've been doing XMPP programming lately), but what about
Bonjour Chat?

https://www.apple.com/support/bonjour/

Bonjour Chat is basically XMPP stanzas sent via an IP multicast group
(if you watch a relatively large LAN comprised of Macs and Ubuntu
machines you can catch quite a bit of this traffic). There are
already a couple of implementations of the protocol that could be used
as a base:

https://stackoverflow.com/questions/1916017/simplest-way-to-publish-over-zeroconf-bonjour

https://pypi.python.org/pypi/pybonjour

So, it seems reasonable to state that it could be used to connect
ad-hoc MUCs running on arbitrary systems so long as they're on the
same multicast group.

> guy in melbourne was trying to sell me on the idea of an inmemory
> gitodb, basically expiring objects in response to memory pressure
> (fixed allocation at boot time, although no reason you couldn't
> balloon).

What about a JSON document store? CouchDB is really heavyweight
(written in Erlang) but what about one of the re-implementations
written in JavaScript, which do the same thing but with a much more
lightweight back-end?

https://github.com/nick-thompson/pouchdb-server

https://github.com/nick-thompson/express-pouchdb

> Obviously this is still at the "back of the envelope idea" stage,
> but it sounds fun. I ight see if I can flesh something out, I've
> got a few days pretty much dedicated to hacking by a pool on my
> defcon trip.

We should probably set up a conference call to discuss this more.

- --
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

"Never underestimate the importance of a cheap laugh." --Plucky Duck

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREKAAYFAlNJ9kAACgkQO9j/K4B7F8G2BgCcCbyp+mMHPi3MYrbShhvvdcL0
Fs4AniaUDAitovR91gM7CqcQJUf16Yu7
=SOsS
-----END PGP SIGNATURE-----

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/27/2013 01:10 AM, Mikael "MMN-o" Nordfeldth wrote:

> Unfortunately XEP-0174 doesn't support group-chat, but assuming one
> is interested in putting the effort of designing a protocol for
> this - I think it's a good idea to kickstart from this already
> existing protocol base. .)

There might be a way to fake it, though.

Set up an XMPP server on each node. Hardcode an anonymous MUC in the
server's config file. Stick a web-based front end on it. Then
autojoin a single bot that sits in the MUC collecting XMPP stanzas.
It depackages the useful stuff from every stanza, bundles them into
the message field of a single stanza, and blips them across the
network using Bonjour. Other bots pick up the message packets,
confirm that they haven't heard them yet, and inject them into the MUC
they consider home with a single stanza.

Deduplication is going to be an issue, though.

> No central directory or anything, and DNS-SD can be forwarded
> within a mesh. Commotion Wireless has a plugin for this bundled
> with their fork of olsrd (in lib/dnssd):
> https://github.com/opentechinstitute/olsrd

Nice!

- --
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

"Never underestimate the importance of a cheap laugh." --Plucky Duck

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREKAAYFAlNJ9/QACgkQO9j/K4B7F8G5sQCfQiZ7vMx9y93Rg9h4CEyOhO//
PqsAoIF/e5+xGDNTF6s2GcEfRWidbeIf
=VbgE
-----END PGP SIGNATURE-----

[John]

Does the Byzantium mail group have a 'set nomail' option, and if so, how
we reach it?

I'd like to read the latest posts in the web archive rather than my
mailbox, as well as retain the power to post my own questions now and then.

Thanks,
John

[shawn wilson]

It's a Google group, so yeah you should be able to. However, I'm not so good at finding what I want in the Google groups interface (I should Google about that) so YMMV.

--
You received this message because you are subscribed to the Google Groups "Project Byzantium (Emergency Mesh Networking)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Byzantium+unsubscribe@hacdc.org.
To post to this group, send email to Byza...@hacdc.org.
Visit this group at http://groups.google.com/a/hacdc.org/group/Byzantium/.
For more options, visit https://groups.google.com/a/hacdc.org/d/optout.

[John]

 
Ah, thanks.  I saw the Google link at the bottom of every message but got confused because the list domain is @hacdc.org. 
 
FYI I clicked on [person-gear icon] -> Membership and email settings -> [combo option]Don't send email updates. 
 
Gracias,
John 

 
 
On 4/13/2014 7:05 AM, shawn wilson wrote:

It's a Google group, so yeah you should be able to. However, I'm not so good at finding what I want in the Google groups interface (I should Google about that) so YMMV.

On Apr 13, 2014 6:52 AM, "John" <jcat...@gmail.com> wrote:

Does the Byzantium mail group have a 'set nomail' option, and if so, how we reach it?

I'd like to read the latest posts in the web archive rather than my mailbox, as well as retain the power to post my own questions now and then.

Thanks,
John

--
You received this message because you are subscribed to the Google Groups "Project Byzantium (Emergency Mesh Networking)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to Byzantium+...@hacdc.org.

To post to this group, send email to Byza...@hacdc.org.
Visit this group at http://groups.google.com/a/hacdc.org/group/Byzantium/.
For more options, visit https://groups.google.com/a/hacdc.org/d/optout.

--

You received this message because you are subscribed to the Google Groups "Project Byzantium (Emergency Mesh Networking)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to Byzantium+...@hacdc.org.

[Fabián Bustillos Vega]

What about PSYC? http://about.psyc.eu/

It touts more scalability http://about.psyc.eu/Scalability and multicast http://about.psyc.eu/Multicast

There is also the possibility of using clustering nodes with XMPP http://www.process-one.net/docs/ejabberd/guide_en.html#htoc84 or shared rosters.

[The Doctor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04/13/2014 01:51 PM, Fabián Bustillos Vega wrote:

> What about PSYC? http://about.psyc.eu/ It touts more scalability
> http://about.psyc.eu/Scalability and multicast
> http://about.psyc.eu/Multicast

Funnily enough, I came across PSYC a few days ago and then forgot all
about it. Are there any web clients for it?

> There is also the possibility of using clustering nodes with XMPP
> http://www.process-one.net/docs/ejabberd/guide_en.html#htoc84 or
shared rosters.

I'm not opposed to clustering XMPP servers, though I do have a few
reservations about that. The way it's documented it seems like doing
ad-hoc clustering (nodes come and go without warning or pre-planning)
isn't really doable. It might be but I think it would take hardcoding
some crypto secrets into the distro itself, as well as some
significant shelll script jiggery-pokery on the back end.

The Erlang runtime is also pretty hefty for a LiveCD environment (on
my laptop, 105 megabytes installed).

Is there anyone else here who's knowledgable of PSYC, who could maybe
brief us on it?

- --
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: https://drwho.virtadpt.net/

*keytar solo!* *storms offstage...*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREKAAYFAlNMlxIACgkQO9j/K4B7F8FEiwCffKoCzE+l8FBuoEan8HQvQZMl
I0sAoLa7mknB1x2ZLs1i4Dg4uc6Bh0SV
=CcCX
-----END PGP SIGNATURE-----

[Fabián Bustillos Vega]

It does come with its own webchat client: https://psyced.org:33333/PSYC/

http://about.psyc.eu/Software

[Paul]

Oldish thread, I know, but found a project not yet mentioned, for the meshable IRC concept:

https://github.com/RocHack/meshchat

From description:

A decentralized chat network for cjdns, with an IRC front-end.

It discovers peers by pinging all the nodes in your local cjdns routing table.
It makes connections between other peers running meshchat.
It serves an ircd that you can connect to with your regular IRC client.

So, unless we'd like to integrate cjdns into the mesh (I like the idea, but...), we'd need to fork the code and rewrite it's discovery routines to utilize mdns/avahi or the like.

However, other than that, it seems quite suitable for what I believe are this projects' purposes, and the desires expressed here...

[Ben Mendis]

That sounds an awful lot like it's just a cjdns-specific version of what Hax and The Doctor threw together a few releases back.

I didn't look deeply at the IRC implementation so perhaps one of them could speak up on the matter.