arades79/hyperdome

the safest place to reach out

hyperdome's Issues

add option to server to force a time limit on conversations

In high-volume scenarios it may be beneficial for counsel and help-seekers to be time limited to ensure wider base of people is reached.

Add web-based admin portal for hyperdome_server

using a web page to administrate servers (namely adding/removing counselors) will ease administration.

Implement config CLI along with refactor of configuration adding more relevant options

While implementing the base level CLI, stubs were left to handle configuration from the CLI, however when looking into implementing it, the implementation seemed too messy to implement in a clean way. Thus the config should be refactored to make the CLI implementation easier. The config CLI can also be lifed into common code so both server and client can have good interfaces for settings/configuration, with server and client only extending with the options they need.

enter button to send

simple UX enhancement, should also have a setting to enable/disable

better exception handling

Primarily an issue in the client's threads.py, where all exceptions MUST be caught as pyqt cannot pass exceptions back to the UI thread without crashing the application.

Currently exceptions caught are too generic, and the actions taken on the exceptions discard useful information.

Linux OS not properly detected during Tor configuration

Linux based hosts should be allowed to use "bundled" Tor option even in developer testing.

Instead the user is warned that bundled Tor is only available on Linux machines, even if the user is on linux

This is likely either due to bad default configuration, or poor detection of underlying OS at least in 'developer mode'

get client working with hidden services

the client currently only works with local hosts or 'clearnet' hosts. Attempts to configure using the Tor socks proxy have failed.

Make message display scrollable

Currently the message display panel will fill in top-bottom and then wrap horizontally, rather than immediately begin scrolling vertically

Add server peering/counselor key sharing for servers

As part of hyperdome's ideal federated system, and to allow hierarchical sorts of nodes, it would be useful if servers had APIs defined to share the public keys of their counselors either individually or wholesale. This can allow for clusters of servers that have common trusted counselors to service multiple populations. This can also be used as a way to implement a sort of web of trust. A server could be configured to allow easy sign ups for counselors that are present in other servers in its list of trusted servers.

Servers should be able to control both read and write privileges of counselor public keys to protect privacy of their counselors if they are especially vulnerable. Servers should be able to do either one-time requests for arbitrary lists of counselors, or easily set up jobs to synchronize counselors between instances.

The trust that these sort of peering setups could provide may also provide a good fail-safe in case a counselor ever becomes compromised, as a revocation could be broadcasted to known peers.

move to python 3.8

Previous PR #47 attempted to update all dependencies to most up-to-date, but an issue in the tor library used, stem, prevented its use due to an unfortunate assumption about dictionary layouts that was rectified in 3.8. Since then a new release of Stem has been released, once this is verified to fix the issue more underlying dependencies and the required version can be bumped.

Once bumped some python 3.8 features can be implemented to the code, bringing readability and performance enhancements where applicable.

Line doesn't do anything

The url variable does nothing. Unclear what its purpose is.

hyperdome/hyperdome_server/__init__.py

Line 127 in b331690

# Build the URL

recreate tests

Tests from onionshare source need to be updated where applicable for hyperdome

Use a production server for releases

Werkzeug is not a robust server for a system expected to have many clients and high uptime.

There are also servers/WSGIs that can be used to offer enhanced security and better performance.

Unfortunately an external dependency will complicate server installation. When this change is released it should provide a docker container option

Automatically disconnect when other party disconnects

When one member of a chat disconnects, the other user is stuck in a limbo where they do not know that the chat has ended, and messages are sent to a null user id.

Experimentally a solution with an extra call, called once every x get messages calls, which returned the status of the active chat works, and a route was created. However this solution was buggy, and another solution may be cleaner to implement

Encrypt chats between guest and counselor to make them unreadable by server

By implementing some form of E2EE scheme, guests and counselors should be able to send messages to eachother such that only they can see the messages. Currently messages are stored in plaintext in a buffer on the server during transit, which means someone with access to the server could theoretically read the contents of those chats.

new CSS for client

It would be uncouth to re-use onionshare CSS. Having a soft inviting UI style would help users feel more comfortable.

Error in window close

This is why you don't catch generic exceptions. This line will always fail because server_status is undefined.

hyperdome/hyperdome_client/hyperdome_client.py

Line 411 in b331690

if server_status.status != server_status.STATUS_STOPPED:

update documentation

Most documentation and other materials such as icons and links are still referencing onionshare. Currently someone hoping to build or use the project may become confused by the mixed references and lack of consistent mission statement or branding.

Stop catching BaseException

Catch the specific exception. There are so many bugs I've found that are just being caught by BaseException.

add 'void mode'

in void mode, the server is the recipient of all messages, all messages are displayed publicly at the server's onion address for some adjustable time scale. Hypothetically allowing users to "shout into the void" may be a catharsis not requiring a counselor. This option should be toggle-able from the server, and a user should have to choose to take part.

Should the UI classes contain as much logic as they do?

Currently, a lot of the logic is being performed in the UI classes, like HyperdomeClient.
The issues with this:

• Tests will be more difficult to run
• UI changes could break logic
• Feels like poor programming

I think we should keep the logic in HyperdomeClient, but move the UI aspects to a new class.
Do you agree?

Make network requests and other IO async to avoid UI stutter

polling the server for new messages makes dragging the window noticeably laggy. Networking should always be async in the first place.

make hyperdome server decoupled from onionshare code

remove file sharing specific code, remove requirement of needing to share a file to start a server, change command line server arguments to relevant commands

Should IPv6 be supported?

Tor IPv6 support is still relatively new, and according to their documentation "Note that as of 2018 there aren't many IPv6 users, or IPv6 guards, so Tor over IPv6 is less anonymous than Tor over IPv4"

https://2019.www.torproject.org/docs/faq.html.en#IPv6

Perhaps this should be an option. Should hyperdome adoption ever be wide enough, it may be a good source of IPv6 relays.

Tray icon shows after exit

When hyperdome client exits, the tray icon is often still present in the tray, and is subsequently deleted after the mouse cursor hovers over it. This is indicative of poor cleanup code.

Change signal binding on HyperdomeClient

signals are currently class variables in threads.py, this was the root cause of actions being duplicated in issue #52 . The solution used to close the issue was to disconnect signals before connecting them. However knowing this cause a better solution can be implemented with either setting signals in the client's init, or changing the tasks to make the signals instance specific.

The tasks used are also poorly implemented, and should be refactored. In this refactoring care should be taken to make sure signals intended to be instance based should be instance based. Likely errors can be class based, and results should be tied to instance.

Support multiple counselor adding policies

Not every server will have the same use case. It is plausible some servers will be loosely administrated, and open to allowing anyone to be a counselor, where some groups would want thorough vetting of all counselors, and need to add them only manually through administration. These could easily be controlled with settings inside the server that communicate the policy to connecting clients, and then depending on the connected server's policy, a user could sign up as a counselor for that server from within the application, be provided an administrator email to request access, and possibly other policies.

store and send passwords in a secure way

Plaintext is unnacceptable for storing passwords. It's important that integrity of counsel is guaranteed as much as possible. Some form of salted hashing should be used. Implementations likely already exist in libraries

counselor message submissions require username and password each time

Would be better if counselors were authenticated once and held a token/cookie for authentication, each time the token is used refreshes a timer that determines if the counselor is active (only active should receive new seekers)

Therapist clients recieve error text continually when connected to empty server

When a counselor connects to an empty server (no guests waiting to connect) the chat window fills with error messages, and will not connect to a guest after one connects

example

integrate CI for tests and lint

Onionshare has a circle CI configuration that nearly suits our needs. It will need to be updated for any new dependencies, remove testing for older python versions, and the linter should be changed to bandit for greater security compliance.

Should language support be removed?

Currently there's support for different languages, but at Hyperdome's currents stage, it will not be feasible to continue supporting different languages for new features. I propose we remove different language support for the time being, and then readd it in the future if Hyperdome becomes popular enough to justify it.
Thoughts?

make chats peer-to-peer

having chats routed through a central server boasts privacy and scaling concerns. Ideally the chats operate similar to Ricochet once established, with minimal server communication for arbitration, but message contents only being sent between 'counselor' and 'guest' by each establishing their own local hidden service to send messages to. This also alleviates needing to poll the server for new messages.

re-create settings page for relevant settings

settings page is still unchanged from onionshare, many settings crash or are undefined

Android and iOS apps

Gettings the client on as many devices as possible will greatly increase adoption. There have been solutions to build pyqt apps for Android in the past, but I'm unsure if these are maintained.

Add administrative abilities to server CLI

Counselors are currently only registered inside of the client, with the admin password being embedded and hardcoded to allow this functionality.

Hyperdome server should have command line arguments, and or configuration files to manage enrolled counselors.

This will also help for testing purposes, as adding a counselor currently either requires the hardcoded hack used in the client, or use of an API tester such as postman.

In the future a web based console (#3) is the ideal management interface

Fix hyperdome_connection test for API changes introduced in 0.1

The hyperdome connection integration test needs to be updated to reflect API changes made. The existing integration test uses hard-coded API calls external to those used in the client to avoid the pyqt dependency. In 0.1 release most API calls are moved to package level functions which can be used in the integration test to verify both server and client are working as expected.

Note that this integration test is not a replacement for good unit tests, but serves as a good sanity baseline for changes.

GUI actions are being duplicated/repeated

spawning of windows, threads that execute after a button press, are being replicated, seemingly by the number of times the action is performed. For instance, sending a message that results in a failure will spawn an alert dialog. If the message is attempted to be sent again, it will result in two HTTP calls, and two errors recieved, a third attempt will render 3 errors, etc.

Configure Tor for non-exit relay ability

At minimum the server element should have the ability to run as a non-exit relay. Ideally, in exchange for anonymization and traffic input, organizations choosing to host a server should have their server running as a relay to expand Tor capacity.

While forcing the organization to act as a relay would be too strict, having that be the default option, and having an easy opt-out would be a good way to have the project support Tor.

web-based client

Allow users to simply go to the onion address from a TOR enabled browser to connect to counsel instead of going through the client (may conflict with peer-to-peer)

Change all references to onionshare/micahflee in edited files

What's the comment for if the code is gone?
Also, Hyperdome*

Originally posted by @makusu2 in #77 (comment)

Simplify os-specific pathing

We can simplify a LOT of their directory-searching code using pathlib. It'll make things much cleaner. Planning on doing this after I finish linting.

add TOR and counselor indicators

onionshare used a status indicator for if the server was online. This should be repurposed to show that a user is properly connected to tor, and another similar indicator should show when a user is successfully connected to counsel.

Should older Python versions continue to be supported?

Onionshare does a good job of keeping code working on older versions of Python, but that limits us to older features of the language, which will make for less elegant code. Can we enforce Python3.7, or should we continue support of older Python3 versions?

General vestige code removal

Ongoing process to remove pieces of onionshare that are irrelevant, or work them into the hyperdome design

change default hidden service behavior

Onionshare defaults to creating an ephemeral unique hidden service every time one is spawned. While this functionality could be useful in some contexts, this should not be the default for Hyperdome systems. Users should expect consistent server URLs, and the ability to skip creating and destroying hidden services for every server launch will be a better experience.

Slug URLs are also unused, and the functionality of these slugs is not necessary for Hyperdome's use case. Thus the default behavior should not create or attach slug endpoints.

Are we leaking user traffic?

https://2019.www.torproject.org/docs/faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks

https://2019.www.torproject.org/docs/faq.html.en#SocksAndDNS

Tests need to be ran to ensure hyperdome doesn't cause any leaks. Other documentation may help for fixes if hyperdome is not compliant.

Error in window close number 2

More issues with undefined variables. OnionShareGUI is never defined, but it's always caught in this method.

hyperdome/hyperdome_client/hyperdome_client.py

Line 415 in b331690

if self.mode == OnionShareGui.MODE_SHARE:

build binaries of application

An overwhelming number of users will not compile from source or run through a python interpreter, Binaries need to be made available for the big three desktop platforms at minimum on every major release

Add capacity option to server

Letting infinite people enqueue for a server may not be the fairest to either the people seeking guidance or the people providing it to have an anxiety producing ever-growing list of people to attend to.