A improvement of sahe, maybe?

Having no requirements for libraries where we'd just end up guessing numbers is fine, but there are some libraries for which we do know the minimum required version.
We should add those to haskell-ricochet.cabal.

Should we introduce a check and a return type of Maybe ByteString in dumpPacket or do we just asume that we generate correct packets everywhere?

GitHub sucks for lots of reasons. Some of them are:

• Lots of things cannot be done without running proprietary JavaScript
• They are a centralized service
• Their backend is not free software (by that, I mean sth. similar to the AGPL)
• Issue tracking data cannot be exported
• You cannot create pull requests without a GitHub account

Thus, I propose to host stuff ourselves. A simple git repository and mailing list would suffice for the beginning. That would solve all of the points above.

haskell-socket has got a better, platform independant POSIX networking interface.

It would be nice to have a higher level abstraction of this, in case we or our libraries’ users will want to support future (or own) versions of the protocol.

We need to find a crypto library with haskell bindings (or create/improve bindings to a good crypto library ourselves), in order to implement some parts of the protocol. See AuthHiddenService. We need:

• A good source of random data
• DER Encoding of 1024-bit RSA Keys
• RSA signing
• HMAC-SHA256
• Whatever it takes to calculate the .onion address out of an RSA key

See On the state of cryptography in Haskell.

There’s lots of undocumented code. Assigning @froozen at his request.

The protocol we’ll implement does a lot of serialization using google’s protocol buffers. The protobuf package enables us to generate haskell code that does the parsing and dumping.

When we started out, we decided we wanted to have working C-bindings as well.
We should put them in another repository, once we get to it.
This issue serves only as a reminder of that fact.

Lenses generated via template haskell don't have any haddock documentation which they should.
The only solution I see is writing them manually and documenting them.

As we're exporting our own monad, we should provide some pleasant functions to "run" it.
I'd propose
startRicochet :: Socket -> [Contact] -> PortID -> Map Word8 (Connectiont -> Ricochet ()) -> IO ()
and
startRicochet' :: ByteString -> PortID -> [Contact] -> PortID -> Map Word8 (Connectiont -> Ricochet ()) -> IO ()

The second one takes the private key and the Tor control port and does the port-mapping for the user.

#4 , #3

The idea was to first write a library and later write a CLI for it

Could be an interesting thing to try out and limit effects, i. e. shaping our very custom effects.

README.adoc should be rewritten at some point — for good reasons.

I'm not sure if only I have this issue, but I need to run the demos as root, otherwise I'll get the following error:

server: /var/lib/tor/control_auth_cookie: openBinaryFile: permission denied (Permission denied)

This is quite problematic as users will need root permissions to run anything using haskell-ricochet, which makes it damn near worthless.
Any ideas on how to fix this?

We’ll want to respond to errors, eg. see Connection.hs.

We need send to connect to and via Tor.

We will need a module with nice crypto-related utility functions.
One thing we need is the generation of 1024-Bit private RSA keys in base64 for network-anonymous-tor.

Problems could exist:

• …in introductionParser
• …in initConnection

The Network.Ricochet module still needs module header documentation.
As this will be the main module, its documentation should contain a lengthy explanation of the project, as well as example code.

I tried to add a pre-config hook to Setup.hs, using this code:

import Distribution.Simple
import Data.Monoid((<>))

curry2 :: ((a -> b -> c) -> (a1 -> b1 -> c1) -> d) -> (((a, b) -> c) -> ((a1, b1) -> c1) -> d)
curry2 = flip (.) curry . flip . flip (.) curry . flip

combine' :: (Monad m, Monoid b) => (a -> m b) -> (a -> m b) -> (a -> m b)
combine' f g x = f x >>= \rf -> g x >>= \rg -> return $ rf <> rg

--combine :: (Monad m, Monoid c) => (a -> b -> m c) -> (a -> b -> m c) -> (a -> b -> m c)
--combine = uncurry . combine' . curry2

preConfHook = preConf simpleUserHooks `combine` const const (putStrLn "test")
main = defaultMainWithHooks $ simpleUserHooks { preConf = preConfHook }

Sadly, the commented out part doesn’t compile.

Our current policy is to just not care about the style and run stylish-haskell sometime later, when noone currently develops any PR. I don’t like this, since the includes look ugly for a long time.

I’d propose to agree on a simpler includes style, since that way, the includes will look good all the time, and we won’t have to arbitrarly specify some point in time where noone develops any PR. It could always be that someone we don’t know is currently working on some great improvement, and he isn’t motivated anymore as soon as he sees himself facing a huge amount of work because of merge conflicts.

Please reference every issue regarding the library to here. More complicated problems can be discussed here.

This will require a pull request to network-anonymous-tor. For now, I propose to let the users configure it themselves.

We should write a lot of test cases and use a CI service for automatic testing on Github.

What should one use to test Haskell applications? Something usable trough cabal test I suppose.

Well, that was the error message when trying to build / configure cabal.
Assuming runProcess to be meant, it's complaining about Monoid not being in scope. Missing dependency?

• Is it a Ricochet User, Instance or Node?
• …

We chose protocol-buffers and hprotoc in #1, now let’s put it to use! We’ll also want to access them using lenses.

Running client and telling it to connect to the server doesn't seem to be doing anything for me.
Looking at its code, it seems like it should print Connected!, but it doesn't do that.
Am I the only one with that problem or does it not work for you as well?

Somehow, we expect the package to be longer than it is, as we wait for more data even though all of it has arrived. Reading through the c++ implementation’s source code, I noticed they put the size of the whole message, including the header, in there. This is not mentioned clearly enough in the specification, so we should open an issue for it at the main project as soon as we can confirm this is correct.

What license do we want to use? GPLv3 would be a nice choice, as crypto stuff should be as free as possible.

• cabal
• nix
• readme
• license