This is a bit of a rough draft, please also review the project here: https://taiga.getmonero.org/project/vespco-annularis-multisig-monero-marketplace/ https://github.com/annularis/shop

Objective I believe Monero has the objective of facilitating financial transactions in a private and trustless manner. Monero is fairly robust by itself (it is private, trustless, and has multisig), but it does not have the infrastructure around it that leads widespread adoption.

What Is Annularis?

Annularis is open source marketplace software that is, above all else, focused on allowing users to transact as privately, as securely, and as anonymously as possible.

As such, it uses monero multisig for escrow and completing transactions, along with a variety of other tools such as enforcing GPG encryption, 2FA, and being designed in a way that makes it compatible with the best practices on TOR and other anonymity networks. This includes no use of site-served javascript, small pages so it loads fast, and designed in such a way that reduce the number of pages one must visit to use the site effectively.

The secondary goal is to focus on ease of use for all parties. This includes making it easy to setup an instance of the Annularis Marketplace Software, easy to join, and easy to buy and sell items.

If ease of use features conflicts with preserving privacy, security or anonymity they will either not be implemented or be implemented in such a way that the users can disable them without losing functionality.

Further Resources: - https://github.com/annularis/shop, - https://annularis.org/forum, - https://annularis.org/shop, - https://taiga.getmonero.org/project/vespco-annularis-multisig-monero-marketplace

Who is behind Annularis?

Cameron Ruggles AKA Vespco. He is the original founder of this project when it was known as Bitwasp and is active in the Monero community with other projects such as GeoCrypto.io, and advertising Monero on the shroomery every month and selling items at highly discounted rates if paid with Monero. :)

Scott Lemon & his team of software developers. I'm good friends with them, they're local, and excited to get to work on it. Have been very involved with cryptocurrency and we met each other at bitcoin meetups and maker spaces early on in the cryptocurrency scene. Was once a pretty good sized miner.

Possibly help from recent contributors: - Serhack, Serhack has created, among other great things for the Monero community, the Monero PHP Integrations, WHMCS, and is working on a book: Mastering Monero. - Dan Fossi - has helped. Need to get back in touch with them.

Though, the last two are busy with other projects such as Serhack's Mastering Monero Book and may have limited ability to contribute. Serhack & Dan Fossi have contributed the most so far since the revival of this project but it sounds like Scott Lemon and his team are ready to hit the ground running and do most of the heavy lifting from here on out.

Interesting Cameron & Scott live near each other and that makes meetings significantly easier. Serhack, Dan Fossi, and Diamond/XPersonal also are all in Italy and speak both English and Italian. This allows for a pretty decent set of people to work on it, and obviously it is FOSS so anyone else is welcome to help as well.

Milestone 1:

Release a docker image of the most current version of Annularis, located here: The goal of this milestone is to make it easy for others to contribute and help develop the software and begin testing & finding bugs as soon as possible.

Milestone 2:

Integrate Monero into the Marketplace software: This will include having the marketplace admin, vendors, and buyers upload their public keys, which will then we used to derive the corresponding 2 of 3 multisig address which is the pay to address for the buyer. Additionally, it will have pay out addresses for the vendor and return addresses for the buyer.

At this point it will be released as Alpha software

Milestone 3:

Build the Monero Multisig Utility as described here: https://taiga.getmonero.org/project/vespco-annularis-multisig-monero-marketplace/issue/10 & https://taiga.getmonero.org/project/vespco-annularis-multisig-monero-marketplace/wiki/multisig-utility

This uses JS downloaded from Github, verified by the user and saved on a USB stick for later use similar in technique to bitaddress.org or moneroaddress.org

The Monero multisig utility will have the tasks of: 1. Independently verifying that the pay-to multisig address is actually derived from the three public keys provided by the vendor, marketplace, and buyer.

Signing or partially signing the transaction, either to dispute it or to release the funds to the seller. Possibly have some API integration with Annularis based marketplaces to make the process easier & maybe integrated with a transaction push service (likely the seller and marketplace will use this feature the most often and not so much the buyer).

This is currently the easiest and most secure way of doing multisig that we believe end users can practically do. This may change if/when Monero GUI gets easier to use multisig features and is packaged for debain/comes with TAILS by default but we don't want to wait around for that to happen. We are very interested in contributing to rbrunner7 really simple multisig project as this will help our project as well.

Milestone 4:

Ensure that the Annularis software is up to par on features. The required features are listed here: https://taiga.getmonero.org/project/vespco-annularis-multisig-monero-marketplace/wiki/features

As there are 15 to 20 features (some far more involved then others) for milestone 4, this task will take a significant amount of work/time - additionally, it will likely be altered over the course of development. As such, Milestone 4 may be completely finished at a later time then Milestone 5 or larger.

Milestone 4.1 Must implement 2-of-3 Multi-Signature. No centralized wallets.

Must implement 2-of-3 Multi-Signature. No centralized wallets. Milestone 4.2 No JavaScript on your market, except for warning users to disable JS if they have it enabled. If the user has enabled JavaScript while visiting your main page, he must be prompted a warning to set the security slider of the Tor browser to high along with a short description of how to do it.

No JavaScript on your market, except for warning users to disable JS if they have it enabled. If the user has enabled JavaScript while visiting your main page, he must be prompted a warning to set the security slider of the Tor browser to high along with a short description of how to do it. Milestone 4.3 Users have to set their public PGP key on their profile before they can make his first order. You must offer all users 2FA with PGP. It has to be enforced for all vendors.

Users have to set their public PGP key on their profile before they can make his first order. You must offer all users 2FA with PGP. It has to be enforced for all vendors. Milestone 4.4 The PGP encrypted messages used for 2FA must contain a phrase similar to: 'Only valid for ' along with the default random passcode. If 2FA is set, the users should not be able to circumvent it and always be required to enter their password and the decrypted PGP passcode. Furthermore can the encrypted 2FA passcode only be valid for one login.

The PGP encrypted messages used for 2FA must contain a phrase similar to: 'Only valid for Milestone 4.5 When a vendor wants to change his PGP key, he has to sign it with his old one. You can also display this signature publicly for users so they can check themselves that the vendor signed his new key with his old one.

When a vendor wants to change his PGP key, he has to sign it with his old one. You can also display this signature publicly for users so they can check themselves that the vendor signed his new key with his old one. Milestone 4.6 Buyer and seller accounts are different. Buyer accounts cannot become vendor accounts.

Buyer and seller accounts are different. Buyer accounts cannot become vendor accounts. Milestone 4.7 The order notes, in which the customer sends their address to the vendor they are buying from, must be PGP encrypted by the user. If it is not, reject the message and tell the user that he has to encrypt his address as well as other sensitive data before sending it and link him to guides on how to properly do it. The checking can easily be done by looking at the beginning of the message and checking if it is the default string of PGP encrypted message (i.e. '-----BEGIN PGP MESSAGE-----').

The order notes, in which the customer sends their address to the vendor they are buying from, must be PGP encrypted by the user. If it is not, reject the message and tell the user that he has to encrypt his address as well as other sensitive data before sending it and link him to guides on how to properly do it. The checking can easily be done by looking at the beginning of the message and checking if it is the default string of PGP encrypted message (i.e. '-----BEGIN PGP MESSAGE-----'). Milestone 4.8 Delete private messages and order details after a certain time period (not longer than 2 months).

Delete private messages and order details after a certain time period (not longer than 2 months). Milestone 4.9 Use of CSS to prevent reloading pages for small clicks. For example realize some functions like collapsing or expanding a box with CSS instead of reloading the entire page with every click.

Use of CSS to prevent reloading pages for small clicks. For example realize some functions like collapsing or expanding a box with CSS instead of reloading the entire page with every click. Milestone 4.10 For country drop-down lists: put the for example 3 most selected ones on top of the list and sort the rest to alphabetically. That way a good chunk of users do not have to scroll down to "United States" for example.

For country drop-down lists: put the for example 3 most selected ones on top of the list and sort the rest to alphabetically. That way a good chunk of users do not have to scroll down to "United States" for example. Milestone 4.11 make page sizes as small as possible for quick loading.

make page sizes as small as possible for quick loading. Milestone 4.12 If a buyer finalizes early, do not let him be able to leave a review immediately. Instead activate a timer till he can leave feedback (to prevent the infamous 5/5 FE'd* reviews).

If a buyer finalizes early, do not let him be able to leave a review immediately. Instead activate a timer till he can leave feedback (to prevent the infamous 5/5 FE'd* reviews). Milestone 4.13 Vendors should be able to rate customers too.

Vendors should be able to rate customers too. Milestone 4.14 Users should not be able to message other users (to prevent spamming and phishing).

Users should not be able to message other users (to prevent spamming and phishing). Milestone 4.15 For vendors a sales page where they can view all the orders on one screen which includes PGP messages, buyer names and what they paid. That way vendors can mark them all accepted and what not from one screen and not from 50 web pages instead 1 for all 50.

Milestone 5:

Make Annularis extremely easy to deploy as a Tor hidden service using docker images of Annularis and a Tor node. This will be similar to OnionBoat (or other options, lots of people have released & subsequently neglected docker files for running tor hidden services) https://nonconformity.net/2016/06/10/onionboat-using-docker-for-easy-tor-hidden-services/

The goal of Milestone 5 is so that you can have a securely isolated instance of the Annularis marketplace running as a hidden service within minutes and minimal technical experience/knowledge.

Milestone 6:

We need to do a full and intensive security audit and code review of all docker images and of course the annularis marketplace software. This may include HackerOne and various reward bounties.

Milestone 7:

Further develop and organize to make an Annularis Foundation so that we can develop and maintain it further in the future, raise more money independently of the Monero community, and attract developers interested in FOSS. This is important for the sake of adding new and exciting features that are further down the line then what we are seeking funding for currently. An example of such is ring signatures for ratings: this would alleviate the blackmailing problem we have observed on the darknet where vendors can threaten buyers who left a bad rating, and make them change it to a good one, or they retaliate, potentially by swatting them or releasing sensitive information about their whereabout and what they've purchased.

Using ring signatures for ratings could allow buyers to rate sellers honestly with less concern about the seller being able to retaliate, while also this would simultaneously ensure that the ratings are from real buyers.

$100,000 Fundraiser Goal

May do this in $6K to $12K increments to limit everyone's risk but still allow everyone to work full time on it for a month or two before requesting more funding.

While we will likely be able to develop this for less money, it would be really nice to have a good amount to secure this projects continued development.

We're hoping to raise at least $100,000 (~800 XMR) to not only develop all these features but to also give this project a solid future. In the past we've raised a bit of money, and it allows us to do a little bit but it is always a constant struggle. Developers end up working for far less then they are worth and eventually leave to work on some other project that poached them from seeing their work on Github. This project really does offer something that is clearly in demand, is unique from other projects such as Open Bazaar, and can be brought to market much faster then many other projects such as Open Bazaar, Kovri, etc. Much of it is already developed, and it won't be too far out for us to release a working version that is easily and quickly deployable as a tor hidden service using docker containers.

Donation via Monero is strongly preferred but we are also open to receiving donations in BTC, Ethereum, and other cryptocurrencies. These will be converted to Monero and sent to our address so everyone can see where we are in relation to our fundraising goal.

While this is a project strongly focused on using Monero, as it is the only cryptocurrency aligned with the goals of this project, which are privacy, security, and anonymity. It should be clear that this project is good for all cryptocurrencies, and related economy. It is after all FOSS software and anyone will be able to modify it as they wish, to use whatever cryptocurrency they wish.