- Create run-onionr-node.sh to parse env and supply args to run-onionr-node.py
- Dockerfile:
- Run onionr by default rather than bash
- Run as unprivileged user by default instead of root
- Use /app for all code
- Specify python 3.7 (3.8 fails to build cffi)
- Use apt-get rather than apt (apt's CLI is not stable)
- Slight reformatting and consolidation
- do not use devnull in run-onionr-node.py
- Create run-onionr-node.sh to parse env and supply args to run-onionr-node.py
- Dockerfile:
- Run onionr by default rather than bash
- Run as unprivileged user by default instead of root
- Use /app for all code
- Specify python 3.7 (3.8 fails to build cffi)
- Use apt-get rather than apt (apt's CLI is not stable)
- Slight reformatting and consolidation
Docker improvements
- Run onionr by default rather than bash
- Run as unprivileged user by default instead of root
- Use /app for all code
- Specify python 3.7 (3.8 fails to build cffi)
- Use apt-get rather than apt (apt's CLI is not stable)
- Slight reformatting and consolidation
Added custom port and bind address args
- Modify onionr.sh to parse env and supply args to run-onionr-node.py
- Run onionr by default rather than bash
- Run as unprivileged user by default instead of root
- Use /app for all code
- Specify python 3.7 (3.8 fails to build cffi)
- Use apt-get rather than apt (apt's CLI is not stable)
- Slight reformatting and consolidation
- Modify onionr.sh to parse env and supply args to run-onionr-node.py
- Run onionr by default rather than bash
- Run as unprivileged user by default instead of root
- Use /app for all code
- Specify python 3.7 (3.8 fails to build cffi)
- Use apt-get rather than apt (apt's CLI is not stable)
- Slight reformatting and consolidation
made httpapi use ujson
made onionrblocks mod use ujson
made setup config use ujson
made devreporting use ujson
made transports/tor use ujson
made contactmanager use ujson
* made restart more reliable
* fixed banblock not deleting blocks
* somewhat fixed friend endpoints not working with niceware keys
* started working on adjusting mail interface to use div instead of inputs
+ added switcher from dark and light theme
- deleted profiles directory for now
+ added theme config option
* added boilerplate to circle picker and useridenticons
- Replace := with :- as := causes an extra unnecessary assignment each
time it is used
- Use system-wide default dirs based on being EUID 0 rather than not
having $HOME set - with previous logic you needed to unset $HOME to
interact with the GUI
- Default XDG_DATA_HOME to $HOME/.local/share rather than
$HOME/.local/share/onionr as it should not be set to an app specific
dir, and usage as if it is one would result in files being set in the
user's chosen XDG_DATA_HOME directly (not in an onionr subdir)
- Default ONIONR_HOME to $XDG_DATA_HOME/onionr rather than
$XDG_DATA_HOME - see previous
- Put $LOG_DIR under $ONIONR_HOME rather than $XDG_DATA_HOME - see
previous
- Don't bother setting XDG_DATA_HOME since we only use it here
- Default ONIONR_HOME to /var/lib/onionr rather than /etc/onionr for
system-wide as it's mostly state data, not just config
- Make assignments more concise
- Removed -R from chmod - 700 already restricts access to
subdirectories and files, and this chmod would require all files to be
marked executable, which is not necessary
- Specified 0700 in chmod - Make sure setuid/setgid/sticky isn't set
for some reason
- Removed chown - chown is usually reserved for root
- Specify python3 rather than 3.7 - We support 3.6 and probably want to
support 3.8+ too
- Rename OUTPUT_DIR to the more descriptive ONIONR_BASEDIR
- Call onionr.sh rather than onionr.py (nonexistent, presumably
intended __init__.py, but this is better anyway)
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [8.0.1] - 2020-12-22
* Fix subprocess in 3.9x with dumb hack
* Dependency bumps
## [8.0.0] - 2020-12-04
* Decrease PoW until better implementation is made
## [7.2.0] - 2020-12-03
* Purge blocks not meeting current pow on startup
* Check block POW before LAN sync
* WSL fixes
## [7.1.0] - 2020-11-23
* Check for ownership of existing dirs in createdirs, this prevents the rare edge case where a user might use a home directory in a location an attacker could write (allowing arbitrary code execution via plugins). This was already partially mitigated by the chmod of the home directory in any case, but this further fixes the issue.
## [7.0.0] - 2020-11-22
* Removed communicator timers
* Removed direct connections and chat (these will be either plugins or separate programs/processes in the future)
## [5.1.0] - 2020-09-07
* Moved plugin web files to be in the plugin folder to reduce staticfiles blueprint coupling
* Added basic sidebar on index page
* Many bug fixes
## [5.0.1] - 2020-08-08
* bumped deadsimplekv to 0.3.2
* bumped urllib3 to 1.25.10
## [5.0.0] - 2020-07-23
- Removed single-process POW support (was only needed on Windows)
Onionr ("Onion Relay") is a decentralized, peer-to-peer communication network, designed to be anonymous and resistant to (meta)data analysis, spam, and corruption.
Onionr stores data in independent packages referred to as 'blocks'. The blocks are synced to all other nodes in the network. Blocks and user IDs cannot be easily proven to have been created by a particular user. Even if there is enough evidence to believe that a specific user created a block, nodes still operate behind Tor or I2P and as such cannot be trivially unmasked.
Onionr ("Onion Relay") is a decentralized/distributed peer-to-peer communication network, designed to be anonymous and resistant to (meta)data analysis, spam, and corruption.
Onionr gives the individual the ability to speak freely, without fear of surveillance and censorship.
---
# Onionr internals
## Blocks
At the core, Onionr is an anonymous Distributed Hash Table (DHT) syncing prepackaged blocks using a simple Gossip protocol with Dandelion++ as an overlay network on top of Tor and I2P.
Onionr stores data in independent packages referred to as 'blocks'. The blocks are distributed to all nodes, but are not required to be stored. Blocks and user IDs cannot be easily proven to have been created by a particular user. Even if Dandelion++ is defeated and there is enough evidence to believe that a specific node is linked to a block's creation, nodes still operate behind Tor or I2P and as such cannot be trivially unmasked. Anonymity is achieved by a stateless network, with no given indication of what node a block originates from. In fact, since one is not required to participate in routing or storage to insert a message, blocks often do not originate from any identifiable node, similar to how Bitcoin transactions do not necessarily originate from a wallet directly associated with a node.
## Onionr Gossip
Onionr works via epidemic/gossip style routing, with message delivery taking roughly log<sub>C</sub>(N) cycles where C is the number of nodes to send a message to each cycle and N is the number of connected nodes. So a network of 100 million nodes can deliver messages in a few minutes even with high packet loss and malfunctioning nodes.
Through Dandelion++ message forwarding and key privacy, it is intended to be nigh impossible to discover the identity of a message creator or recipient. Via long-term traffic analysis, a well funded adversary may discover the most probable node(s) to be creating a set of related blocks, however doing so would only lead them to a node behind Tor. As the first node that a block appears on is almost always not the creator of the block, there is plausible deniability regarding the true creator of the block.
Users are identified by ed25519/curve25519 public keys, which can be used to sign blocks or send encrypted data.
Onionr can be used for mail, as a social network, instant messenger, file sharing software, or for encrypted group discussion.
The whitepaper (subject to change prior to alpha release) is available [here](docs/whitepaper.md).
Since Onionr is technically just a data format, any routing scheme can technically be used to pass messages.
![Tor stinks slide image](docs/tor-stinks-02.png)
The whitepaper is available [here](docs/whitepaper.md).
## Main Features
---
# Main Features
* [X] 🌐 Fully p2p/decentralized, no trackers or other single points of failure
* [X] 🔒 End to end encryption of user data
* [X] 📢 Optional non-encrypted blocks, useful for blog posts or public file sharing
* [X] 💻 Easy HTTP API for integration to websites
* [X] 🕵️ Metadata analysis resistance and anonymity
* [X] 📡 Transport agnosticism (no internet required)
Onionr ships with various application plugins ready for use out of the box:
Currently usable:
# Roadmap
* Mail
* Public anonymous chat/message board
* Simple webpage hosting - Will be greatly extended
* File sharing (Work in progress)
Not yet usable:
* Instant messaging
**Onionr API and functionality is subject to non-backwards compatible change during pre-alpha development**
(--require-hashes is intended to prevent exploitation via compromise of PyPi/CA certificates)
Require-hashes is suggested for supply-chain security but is optional. The hashes are not correct for ARM machines. If you are just running a node or want a bare-bones install you can use requirements-base-x86.txt and selectively install the requirements.txt files in static-data/official-plugins/ subdirectories
## Run Onionr
* Run Onionr normally: `$ ./onionr.sh start`
* Run Onionr in background as daemon: `$ ./start-daemon.sh`
* Open Onionr web interface `$ ./onionr.sh openhome`
* Gracefully stop Onionr from CLI `$ ./onionr.sh stop`
* Bitcoin: [bc1qpayme9rlpkch0qp3r79lvm5racr7t6llauwfmg](bitcoin:bc1qpayme9rlpkch0qp3r79lvm5racr7t6llauwfmg) (Contact us for a unique address or for other coins)
* USD (Card/Paypal (no account required)): [Ko-Fi](https://www.ko-fi.com/beardogkf)
Email: beardog [ at ] mailbox.org
* Sign up for [privacy.com (refferal link)](https://privacy.com/join/FNNDF) to protect your personal information when contributing or shopping elsewhere, we both get $5 USD.
* [ X ] Implement new block format with verifiable delay function
* [ X ] Implement overhauled gossip system with dandelion++
The new system is separated from the underlying networks used and makes it much easier to implement new transport methods. Dandelion++ is also better than the old block mixing we did.
To facilitate the below market plugin/application, Onionr will need a web of trust system.
* [ ] Web of trust plugin or module
## Market Plugin Release (~10.1)
The Onionr team believes the Monero community is currently lacking a good p2p market, and as such we hope to build a solution using Onionr as a transport. This may be a separate project and as opposed to a plugin.
* A new marketplace plugin will be developed with the following *tenative* features:
All HTTP interfaces in the Onionr reference client use the [Flask](http://flask.pocoo.org/) web framework with the [gevent](http://www.gevent.org/) WSGI server.
## Client & Public difference
The client API server is a locked down interface intended for authenticated local communication.
The public API server is available only remotely from Tor & I2P. It is the interface in which peers use to communicate with one another.
# Client API
Please note: endpoints that simply provide static web app files are not documented here.
* /serviceactive/pubkey
- Methods: GET
- Returns true or false based on if a given public key has an active direct connection service.
* /queueResponseAdd/key (DEPRECATED)
- Methods: POST
- Accepts form key 'data' to set queue response information from a plugin
- Returns success if no error occurs
* /queueResponse/key (DEPRECATED)
- Methods: GET
- Returns the queue response for a key. Returns failure with a 404 code if a code is not set.
* /ping
- Methods: GET
- Returns "pong!"
* /getblocksbytype/type
- Methods: GET
- Returns a list of stored blocks by a given type
* /getblockbody/hash
- Methods: GET
- Returns the main data section of a block
* /getblockdata/hash
- Methods: GET
- Returns the entire data contents of a block, including metadata.
* /getblockheader/hash
- Methods: GET
- Returns the header (metadata section) of a block.
* /hitcount
- Methods: GET
- Return the amount of requests the public api server has received this session
* /lastconnect
- Methods: GET
- Returns the epoch timestamp of when the last incoming connection to the public API server was logged
* /site/hash
- Methods: GET
- Returns HTML content out of a block
* /waitforshare/hash
- Methods: POST
- Prevents the public API server from listing or sharing a block until it has been uploaded to at least 1 peer.
* /shutdown
- Methods: GET
- Shutdown Onionr. You should probably use /shutdownclean instead.
* /shutdownclean
- Methods: GET
- Tells the communicator daemon to shutdown Onionr. Slower but cleaner.
* /getstats
- Methods: GET
- Returns some JSON serialized statistics
* /getuptime
- Methods: GET
- Returns uptime in seconds
* /getActivePubkey
- Methods: GET
- Returns the current active public key in base32 format
* /getHumanReadable/pubkey
- Methods: GET
- Echos the specified public key in mnemonic format
* /insertblock
- Methods: POST
- Accepts JSON data for creating a new block. 'message' contains the block data, 'to' specifies the peer's public key to encrypt the data to, 'sign' is a boolean for signing the message.
# Public API
v0
* /
- Methods: GET
- Returns a basic HTML informational banner describing Onionr.
* /getblocklist
- Methods: GET
- URI Parameters:
- date: unix epoch timestamp for offset
- Returns a list of block hashes stored on the node since an offset (all blocks if no timestamp is specified)
* /getdata/block-hash
- Methods: GET
- Returns data for a block based on a provided hash
* /www/file-path
- Methods: GET
- Returns file data. Intended for manually sharing file data directly from an Onionr node.
* /ping
- Methods: GET
- Returns 'pong!'
* /pex
- Methods: GET
- Returns a list of peer addresses reached within recent time
* /announce
- Methods: POST
- Accepts form data for 'node' (valid node address) and 'random' which is a nonce when hashed (blake2b_256) in the format `hash(peerAddress+serverAddress+nonce)`, begins with at least 5 zeros.
- Returns 200 with 'Success' if no error occurs. If the post is invalid, 'failure' with code 406 is returned.
* /upload
- Methods: POST
- Accepts form data for 'block' as a 'file' upload.
- Returns 200 with 'success' if no error occurs. If the block cannot be accepted, 'failure' with 400 is returned.
# Direct Connection API
These are constant endpoints available on direct connection servers. Plugin endpoints for direct connections are not documented here.
* /ping
- Methods: GET
- Returns 200 with 'pong!'
* /close
- Methods: GET
- Kills the direct connection server, destroying the onion address.
It is intended to log bugs leaking private file system information, block+log network leaks, and block+log eval-like arbitrary code execution. It is not intended to block malicious browser scripts or malicious Python plugins. It cannot work with subprocesses that do not activate the module.
It's not intended to be bulletproof by any means, but it helps.
### What big brother does
* Disk access checks for disk access outside. Only logs, does not block
* Network leaks. (Non Tor/LAN) Blocks and logs
* Arbitrary code execution: logs and blocks non-whitelisted bytecode importing/compiling and subprocesses.
## Sybil attacks
As with any decentralized network, sybil nodes could collude to spy or cause mayhem. Due to the gossip nature of Onionr, sybil nodes would have a hard time fully stopping the network. In terms of spying, they could not conclusively prove the origin of messages due to the multiple transport nature of the network and layering behind Tor/etc.
## Tor configuration
When managed by Onionr, Tor has a control port password that gets stored in Onionr config.
Tor is also configured to reject requests to non-onion services, which helps to stop redirect based denial of service attacks.
## Web security
Onionr secures both it's main web APIs with anti-dns-rebinding logic, which validates the host header used in connections to it. This is to prevent exfiltration of data and side channel deanonymization.
Onionr secures the client API with a token that must be passed in most requests, with the exception of static API files. This is to prevent CSRF and side channel deanonymization.
Onionr binds most services to random loopback addresses to reduce all cross-site web attacks, including discovery of Onionr on a computer from a normal website. This is not supported on Mac because Mac does not support non 'typical' loopback addresses.
Onionr has a strict content-security-policy, rejecting all non-localhost requests and denying inline scripts and similar insecure sources.
This page assumes that Onionr is already installed and normal user requirements are setup.
The Onionr development environment is simple. All one really needs is a supported Python version (currently 3.7-3.8 as of writing).
There are additional requirements specified in requirements-dev.txt
**Developers agree to the [CoC](../../CODE_OF_CONDUCT.md) and to contribute new code under GPLv3 or later**. Developers should stick to PEP8 in most cases, and write unittests or integration tests where possible.
## Developer Scripts
run-onionr-node.py can be used to start a node with specific parameters
Intended to be used from VSCode (but could work otherwise), there are scripts in scripts/ named enable/disable-dev-config.py.
These make modifications to the default config for the purpose of making testing Onionr nodes easier.
Be sure to disable it again before pushing work.
There are also scripts to generate new tests.
*When adjusting PoW, it will make your node not compatible with the existing network*
Generally, one should disable bootstrap list usage when testing non trivial changes. This is a config option: general.use_bootstrap_list. and can be configured through enable-dev-config.py and run-onionr-node.py
# Current state of Onionr [2021-01-14]
Onionr in it's current form is functional, albeit buggy.
## Current major components
Onionr runs via two main HTTP gevent servers serving Flask apps.
Dir: apiservers
* 1 Parent app hosts all public API endpoints for the Tor transport.
* 1 Parent app hosts all UI-related files and endpoints. Some commands and internal modules interact with this API as well
* The HTTP servers have strict anti-dns-rebinding and CSRF countermeasures, so there is a script to craft requests to the UI-related API in scripts/
* Block storage is currently handled via metadata in sqlite (mostly defunct now), and block data storage in a different database. This is in blocks/ in running Onionr daemon data directory
* cryptography is currently handled in onionrcrypto/ except for ephemeral messages which are handled by onionr
* Transport clients run from looping threads mostly created in communicator/__init__.py, this includes block lookups and uploading on the Tor transport
## Road map
There are several big ways Onionr will be improved in the next major version:
* Migration to the [new modular block system](https://git.voidnet.tech/kev/onionrblocks)
* Probability proof of work -> verifiable delay function
* Friend system built on top of signing proofs (Private networks?)
* Gossip transport improvements such as with neighbor improvements. See streamfill/ and [simple gossip](https://github.com/onion-sudo/simplegossip) for incomplete experiments
* Finish removing "communicator"
* I2P transports
* Gossip
* Torrents (patch for sha1?)
* Modular transports
* Currently transports are just threads coupled together.
* It would be better if there was a generic way to tell any loaded transport what blocks are wanted and feed back received blocks to the database
* Migrate to SafeDB for peers and blocks
* SafeDB wrapper that contacts http endpoint to store if it is running, otherwise directly open DB
* Separate UI logic from daemon. Refactor code to
* Improve cryptography
* Restore phrases or deterministic keys (generate key from password, be very careful)
* Change identities to be dual keys (ed25519+curve25519)
* Finish treasurechest
* Interact via [named pipes](https://en.wikipedia.org/wiki/Named_pipe)
* Ephemeral key management
* Encrypt/decrypt/sign/verify functions to keep key out of main memory
@ -20,13 +20,13 @@ The metadata section has the following fields. If a block contains any other fie
## meta
Max byte size: 1000
Max byte size (when in escaped json string format): 1000
Meta is a string field which can contain arbitrary sub fields. It is intended for applications and plugins to use it for arbitrary metadata information. In the reference client, if the data section is encrypted or signed, the meta section also is.
Meta is a string field which can contain arbitrary sub fields. It is intended for applications and plugins to use it for arbitrary metadata information. If the data section is encrypted or signed, the meta section also is.
Common meta fields, such as 'type' are used by the reference Onionr client to describe the type of a block.
## sig
## sig (optional)
Max byte size: 200
@ -34,30 +34,30 @@ Sig is a field for storing public key signatures of the block, typically ed25519
Note: the max field size is larger than a EdDSA signature (which is what is typically used) in order to allow other primitives for signing in alternative implementations or future versions.
## signer
## signer (optional, necessary if sig is present)
Max byte size: 200
Signer is a field for specifying the public key which signed the block. In the reference client this is a base64 encoded ed25519 public key.
## time
## time (mandatory)
Max byte size: 10
Time is an integer field for specifying the time of which a block was created. The trustworthiness of this field is based on one's trust of the block creator, however blocks with a time field set in the future (past a reasonable clock skew) are thrown out by the reference client.
Time is an integer field for specifying the time of which a block was created. The trustworthiness of this field is based on one's trust of the block creator, however blocks with a time field set in the future at the point of block receipt (past a reasonable clock skew) are thrown out by the reference client.
## expire
## expire (optional)
Max byte size: 10
Expire is an integer field for specifying the time of which the block creator has indicated that the block should be deleted. The purpose of this is for voluntarily freeing the burden of unwanted blocks on the Onionr network, rather than security/privacy (since blocks could be trivially kept past expiration). Regardless, the reference client deletes blocks after a preset time if the expire field is either not set or longer than the preset time.
## pow
## pow (effectively mandatory)
Max byte size: 1000
Pow is a field for placing the nonce found to make a block meet a target proof of work. In theory, a block could meet a target without a random token in this field.
## encryptType
## encryptType (optional)
encryptType is a field to specify the mode of encryption for a block. The values supported by Onionr are 'asym' and 'sym'.
Due to the natural trade-offs of implementing [forward secrecy](https://en.wikipedia.org/wiki/Forward_secrecy) in a distributed, decentralized system, Onionr has optional
Due to the natural trade-offs of implementing [forward secrecy](https://en.wikipedia.org/wiki/Forward_secrecy) in a distributed, decentralized system, Onionr has optional ephemeral keys.
Onionr will be accessible over any network interface by default, so make sure to either change the entry point bind-address argument or set a firewall rule.
That said, Onionr does protect it's interface by default with a web token, which will be shown in stdout.
**However, anyone who can access the port may be able to see what Onionr sites you have saved and potentially deanonymize your node**
## View the UI
Visit the address and port for the machine Onionr is running on, for example: http://192.168.1.5:8080/#<long-token-taken-from-stdout>
If you want a secure connection to the interface, either use a proxy such as nginx or caddy, or use [SSH tunneling](./vps-cloud-guide.md).
(Most of the FAQ answers apply to planned features and do not reflect in the demo network)
* How does Onionr route messages?
Onionr creates a message with an anti-spam proof (usually). It is then forwarded between nodes using binomial tree broadcast.
The network is structured based on the particular transport being used, for Tor, .onion addresses are used to determine closeness between nodes.
Churn due to connectivity changes or issues, membership changes or malicious activity means nodes need to sometimes look far away for missed messages.
To help with scale, messages can be intelligently deleted or forwarded, for example a mail message can be marked by its recipient at a given point for deletion, or forum posts can be set to expire after a short period or after lack of activity.
* Why do you use Python instead of [language]?
I'm very comfortable in Python, and I believe it is a maintainable language if you use it correctly with modern features, also it has many quality libraries useful to the project, like pyncal and stem. Most places in the project are IO bound.
* What do you think of bad actors who might use Onionr?
Users should be able to exclude viewing, processing, and hosting content they do not want to. To this end, I want to enable user-configurable filtering based on lists provided by friends, fuzzy hashing, and voting.
Deterministic addresses are simply Onionr user IDs that are generated from a passphrase rather than general entropy.
To generate an Onionr deterministic, create a random passphrase of at least 25 characters of length. **It is very important that your passphrase is highly random. 9+ words is recommended for your passphrase**
Copy your ID from the textbox below the navbar. Publish the ID so that someone (or general people) know your ID to send messages to it. Note that associating the ID with your real ID publicly removes anonymity.
## Sending mail
1. optionally add the recipient as a friend via the friends page.
2. click compose in the mail menu
3. either select the recipient from the friend list or paste their ID in manually into the recipient box
* Single-page sites, identified by the hash of a single page contained within a single Onionr block.
* Multi-page sites, identified by a user ID. Contains directory archives of a full site.
# Metadata Awareness
Before creating an Onionr site, one should be cautious of the metadata one could be leaking. For example, some HTML generators may insert author meta tags. Onionr does not filter out any web page data.
# No JavaScript, no third-party resources
Currently, in order to protect Onionr users, JavaScript is disabled within Onionr sites. JS will remain present in the HTML file, but be non functional. Additionally, third party resources outside of Onionr cannot be loaded.
# Creating multi page sites
Multi page sites are the most useful, as they can contain an arbitrary amount of static files.
To create a single page site, create a directory for your site and write standard HTML file(s) within them. CSS, images and other files can be placed in the directory as well. The home page should be name index.html and in the parent level directory.
Then, create a strong passphrase for the site. If the site will be updated, be sure to write it down or remember it. A strong passphrase can be generated by running:
`$ scripts/passphrase-generator.py`
Sample output: lovesick blubberer haemoglobin... and so on.
## Generating or updating the site:
`$ ./onionr.sh addsite`
All files in the current working directory will be added to the site.
The command will prompt for a passphrase.
After the site is generated, a user ID that identifies the site will be outputted.
# Creating single page sites
Single page sites are incredibly straight forward.
Single page sites cannot be modified or updated, but are somewhat more secure due to having lower complexity.
To create a single page site, write a standard HTML file. Inline or data-uri CSS can be included, as well as data-uri images. Data-URI generators can be found online.
After creating the HTML file, run this command:
`$ ./onionr.sh addhtml filename.html`
![single page screenshot](single-page.png)
# Viewing sites
To view a site, open the Onionr web interface and paste the site hash or ID into the site opener box that looks like this:
[Cockbox](https://cockbox.org/?r=12) is the recommended provider, as they do not demand personal information and accept Monero. This is an affiliate link, which gives us a commission at no expense or complication to you.
1. [Install Onionr like normal](./basic-onionr-user-guide.pdf) or [from Docker](./docker.md)
2. Run with specific host and port to bind to: `$ ./run-onionr-node.py --bind-address 0.0.0.0 --port 8080`
3. Get the web security token: `$ ./onionr.sh get-web` (the long string at the end of the URL)
4. [Configure Firefox for SSH tunneling](https://web.archive.org/web/20210123034529/https://gist.github.com/brentjanderson/6ed800376e53746d2d28ba7b6bdcdc12). `Set network.proxy.allow_hijacking_localhost` to true in about:config
Disable random host binding in config (general.security.random_bind_ip = false) if you have Onionr auto start. You may also want to disable deniable block inserts.
We believe that the ability to communicate freely with others is crucial for maintaining societal and personal liberty. The internet has provided humanity with the ability to spread information globally, but there are many persons and organizations who try to stifle the flow of information, sometimes with success.
Internet censorship comes in many forms, state censorship, corporate consolidation of media, threats of violence, network exploitation (e.g. denial of service attacks) and other threats.
Internet censorship comes in many forms, state censorship, threats of violence, network exploitation (e.g. denial of service attacks) and others.
We hold that in order to protect individual privacy, users must have the ability to communicate anonymously and with decentralization.
@ -63,6 +66,8 @@ Metadata defines what kind of data is in a block, signature data, encryption set
Optionally, a random token can be inserted into the metadata for use in Proof of Work.
The proof of work function should be a Verifiable Delay Function (VDF). We have chosen MiMC for it's simplicity.
### Block Encryption
For encryption, Onionr uses ephemeral Curve25519 keys for key exchange and XSalsa20-Poly1305 as a symmetric cipher or optionally using only XSalsa20-Poly1305 with a pre-shared key.
@ -83,9 +88,7 @@ Blocks are stored indefinitely until the allocated space is filled, at which poi
## Block Timestamping
Onionr can provide evidence of when a block was inserted by requesting other users to sign a hash of the current time with the block data hash: sha3_256(time + sha3_256(block data)).
This can be done either by the creator of the block prior to generation, or by any node after insertion.
Onionr blocks are by default not accepted if their timestamp is set too far in the past, or is in the future.
In addition, randomness beacons such as the one operated by [NIST](https://beacon.nist.gov/home), [Chile](https://beacon.clcert.cl/), or the hash of the latest blocks in a cryptocurrency network could be used to affirm that a block was at least not *created* before a given time.
logger.debug('Couldn\'t connect to any peers.'+(' Last node seen %s ago.'%humanreadabletime.human_readable_time(time.time()-comm_inst.lastNodeSeen)ifnotcomm_inst.lastNodeSeenisNoneelse''),terminal=True)
The files in this submodule handle various subtasks and utilities for the onionr communicator.
## Files:
announcenode.py: Uses a communicator instance to announce our transport address to connected nodes
connectnewpeers.py: takes a communicator instance and has it connect to as many peers as needed, and/or to a new specified peer.
cooldownpeer.py: randomly selects a connected peer in a communicator and disconnects them for the purpose of security and network balancing.
daemonqueuehandler.py: checks for new commands in the daemon queue and processes them accordingly.
deniableinserts.py: insert fake blocks with the communicator for plausible deniability
downloadblocks.py: iterates a communicator instance's block download queue and attempts to download the blocks from online peers
housekeeping.py: cleans old blocks and forward secrecy keys
lookupadders.py: ask connected peers to share their list of peer transport addresses
lookupblocks.py: lookup new blocks from connected peers from the communicator
netcheck.py: check if the node is online based on communicator status and onion server ping results
onionrcommunicataortimers.py: create a timer for a function to be launched on an interval. Control how many possible instances of a timer may be running a function at once and control if the timer should be ran in a thread or not.
proxypicker.py: returns a string name for the appropriate proxy to be used with a particular peer transport address.
servicecreator.py: iterate connection blocks and create new direct connection servers for them.
uploadblocks.py: iterate a communicator's upload queue and upload the blocks to connected peers
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.