Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configure the hidden service automatically #12

Closed
photm5 opened this issue Oct 17, 2015 · 17 comments
Closed

Configure the hidden service automatically #12

photm5 opened this issue Oct 17, 2015 · 17 comments
Assignees

Comments

@photm5
Copy link
Member

photm5 commented Oct 17, 2015

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

@sternenseemann
Copy link
Member

Example torrc commited as of ba810d1

@sternenseemann sternenseemann added this to the TOR Interaction milestone Oct 19, 2015
@photm5 photm5 removed the Library label Oct 20, 2015
@sternenseemann
Copy link
Member

@froozen's Pull Request is pending.

@photm5
Copy link
Member Author

photm5 commented Oct 24, 2015

The PR is merged by now. @froozen does it suffice for our needs?

Do we plan to add a small wrapper to this library?

@froozen
Copy link
Member

froozen commented Oct 24, 2015

I'd propose having the user of the just pass in a Socket when they want to run the Ricochet-Monad, as they can simply open it themselves, if they already configured the hidden service in their tor instance or use network-anonymous-tor to do it for them.
This would clash with #18, though, as network-anonymous-tor uses Network.Socket in their interface, which we would have to use as well then.

@photm5
Copy link
Member Author

photm5 commented Oct 24, 2015

The implementation of accepting a Socket connection in network-anonymous-tor is merely a small wrapper, if I remember right. This means we could rewrite that wrapper to use haskell-socket and add it to this library. Problematic might be that probably there are lots of more libraries out there that support the Network.Socket interface.

What do you think?

@froozen
Copy link
Member

froozen commented Oct 24, 2015

I guess we should have @lukasepple explain to us why he thinks we should use haskell-socket instead and decide then wether it's worth the trouble.

@sternenseemann
Copy link
Member

Platform independant and POSIX compliant interface.

@froozen
Copy link
Member

froozen commented Oct 24, 2015

Platform independant as in Windows compatible?

@sternenseemann
Copy link
Member

Yes

@froozen
Copy link
Member

froozen commented Oct 24, 2015

I don't think better POSIX compliance is an equal tradeoff for compatability to other libraries.
We should use Network.Socket, at least until we start having problems with it.

@sternenseemann
Copy link
Member

Why would we drop compatibility with other libraries?

@photm5
Copy link
Member Author

photm5 commented Oct 24, 2015

Because other libraries might provide means of creating Network.Socket instances. Our library would only be capable of handling System.Socket.Socket instances.

@froozen
Copy link
Member

froozen commented Oct 24, 2015

Because there's a lot of libraries providing utility functionality for Network.Socket that users of our library might want to use, like network-attoparsec. This would be impossible if we used System.Socket.Socket.

@photm5
Copy link
Member Author

photm5 commented Oct 24, 2015

:)

@sternenseemann
Copy link
Member

I see.

@sternenseemann
Copy link
Member

What is the status here?

@froozen
Copy link
Member

froozen commented Nov 12, 2015

Should've been closed by merging #33.

@froozen froozen closed this as completed Nov 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants