Message board for multi-protocol project (working title Misq) #51
Comments
chimp1984
added
a:proposal
I think this is important. Smartphones are the main tool people use right now. Also, and maybe later in the future if this approach works, some kind of integration of this new feature within a popular mobile wallet that supports LN (aligned with Bisq principles, of course: open source, non custodial, etc...) could be very useful as we could have a lot of potential users on board immediately. It could be the decentralized non KYC version of the button "Buy Bitcoin now" that many wallets have now in their UI (including hardware wallets like ledger).
|
|
Ledger has a done a great job UX wise. They way how they add a multitude of different apps to the hardware wallet is great and even all comes with lot of complexity it feels not that complicate. This "app" model might be usefule for the UX challenges of the multi protocol model as well. |
I think this will occur immediately. Either the service can be ran completely anonymous to prevent legal liabilities for the operator or we introduce a kind of access control to the service. If it is not too much effort we could limit access via a simple code and every new user has three new codes she can share with her friends (we could even use this to market the service 😉). So when abuse is detected the access code that is linked to the entries can be revoked. The only problem I see is that the entries get linked with the access code, but we have this problem anyways if they leave some kind of identity in the spreadsheet. If someone wants to prevent this, she could just use just one access code for one entry (similar to onion addresses on Bisq). |
|
A first approximation to necessary fields:
I would keep it as simple as possible but also as open as possible, even allowing users to input whatever asset or payment method they want initially (instead of giving them a dropdown to choose from). I would also keep every offer on the same table and then allow users to filter/search. What is the point of creating a dozen markets for anything lower than 1000 offers? |
|
@ripcurlx |
|
I don't have the necessary skills to lead the project, but I am willing to help with several tasks. For example I would happily do this:
|
|
@flix1 Also I think the both asset amounts should be the primary data not one asset amount + price. The price is a result of both amounts. |
|
I think for contact we could use an URL. Twitter link, URL link to Telegram nickname, email,... People can/should create burner accounts so the privacy and security risks can be mitigated. |
|
@chimp1984 changed according to your suggestions. I think the price column is important for filtering/ordering purposes, but should be autocalculated as a result of other offer inputs. |
|
How would the moderator know when an offer was "taken" and should be taken off the list? |
|
I think a date field which gets automatically set at creating time (not editable) can help to clean up old offers as well to sort for age. Users should remove themself and if no they might get too many contact request, so most might do that. Beside that we can set a rule that offers older then xxx days get removed.... |
|
The inspiration is Bisq Keybase group, right? I didn't see how it works there. Was it all in the public chat (someone say "I want to sell", someone else replies "I want to buy, pm you", or in any other way? If it's in the public chat, then it was kind of visible which offers were taken (which is one reason that it functioned). Since this is the inspiration, maybe we should take it into account. Not sure about others, but I'd be frustrated super quickly if I send 2-3 messages which are either not replies, or the reply is "it's not relevant anymore". |
|
Here are the docs: https://bisq.wiki/Buy_BSQ#Buying_small_amounts |
|
I looked at the Bisq trading group now. People there report 'completed trades", so it's "off the table". Another feature it has is that you actually look only at the last 3-4 offers (I can't imagine many people scrolling up to look for more). You also get notified of new offers (if your keybase is open with notifications on). This all works because it's super small. Less than 50 people, so not many messages and spam. The people all of them need to be very "specific" to even find it, so it ensures security by that. This message board, as I understood, is aimed to be more public and on a greater scale. I'm not sure how the properties the small Keybase group provides would translate then, but we'll see. But anyway, if I understood, the goal is not less to create a p2p network that can support such apps in the future, than to create this specific message board. For this cause, the project seems great. I would propose to make only the version with a frontend in JS+CSS+HTML (why make two?), so it's kind of a decentralized website where the backend is a p2p network (you know how much I love these;)). However, even then I'm not sure how it would work on mobile since p2p and mobile are not best friends afaik (it kills the battery), but I'd love to be corrected.. |
|
Hi @chimp1984 I think testing the ideas proposed in bisq-network/proposals#330 would be great. I am a little confused with what aspect this project is looking to test with the creation of a message board. Is it the social trading aspect? or both the social trading aspect and the collateral aspect (if taken to Bisq)? Social aspect
Where does the reputation aspect come into play? Would traders build up reputation on a burner account? The Keybase channel has worked well so far and AFAIK there have not been any scammers to date. It is however still small and I think benefits from the protection of an existing community. Hopefully potential scammers would quickly be called out and discovered. If the message board became popular what would stop people creating @chimp1984 usernames with your avatar and making lots of offer to sell BTC only to never be heard of again? One only has to watch a couple of youtube bitcoiner videos to see how common this sort of scam is. Collateral aspect If the message board where to be used to discuss offers that someone was looking to make / take on Bisq one of the problems I see is people requesting offers and not taking them. This can be a cause of frustration, especially when mining fees are high. I have experienced this a few times in trader chat when someone asks for an offer to be posted only for them not to accept. In your comment here bisq-network/proposals#330 (comment) it suggests a trade fee be made when making / taking an offer. I think this would be a great way to negate the issue above, but it does not sound like this would be available in the MVP? However I might have misunderstood how the collateral aspect would work? |
Yes the spreadsheet is only a temporary quick and cheap test.
To have it also in Bisq as add-on can bring some benefits and it might serve as base for further protocol additions. Maybe the next step will be to add another base layer with an external wallet, but its all implemented on the new Misq app and just runs inside Bisq to help to bootstrap it... But its still a bit early for that phase... too much basic questions first to get solved.
I would see use the mobile version as remote control only and have some public nodes they are connected to for all the p2p functionality. There could be multiple public nodes and users connect randomly or choose their own one. The data lives all in the p2p network, so it does not really matter. As long there are no keys or privay data required any public node can be your cloud host. The control for removing an offer though requires a key, but thats rather rivial and can be done on a mobile app. E.g. You attack a pubKey to your offer, and for removal you need to sign the offer data with your priv key which is stored on the mobile. The remove request will only be execuited if the signature matches the pubKey. |
Not really the social aspect, rather to bring the keybase OTC model into Bisq and further develop it to see if the no/low security model has sufficient demand and if it can work in a little broader context as in keybase.
They could use that to share then their real account but not have exposed their real account to the public but only selectively after one requests to trade.
Yes I agree it will likely become problematic as soon its larger. But its intended only as a first cheap test, as soon the P2P network is there we have already better tools to deal with spam/scammers. As @ripcurlx posted to add access control via coupons shared to friends might be an approach and would introduce some social aspect.
I think that use case might be a bit out of scope for the base experiment. Lets focus on the more straight use cases where people post offers. More complex interactions/contracts can be added over time if the simple stuff works good enough.
Ah sorry that was not meant that concrete. How a fee model can be applied is still an open question. For this project here I consider like in keybase that there is no fee. I think as soon security is provided a fee is justified and as security is mostly connected to a blockchain transaction the model to take a part of the trade might be replicated. But maybe there are other new ideas like burning BSQ for reputation which can serve then as revenue model as well as (limited) security model. I have some rough ideas around identity and it could help to mitigate many problems (scam, spam,...) and I think it can be done in a way where the privacy of the user is preserved. But thats for another proposal ;-).
Maybe we mixed up too much with the ideas @flix1 posted in his proposal. I still don' understand exaclty how BSQ bonds could create real security for multiple trades/traders. I doubt its possible. Then there is a weaker form of security which can be derived from BSQ bonds and that might be useful (e.g. user locks up 10000 BSQ is unlikely to scam one for 100 EUR). This UX challenge we can use as starting point to work on the overall biggest challenge of the Bisq 2.0 idea. |
|
Actually adding a chat room might be useful. So newbies quickly can find help. Of course there is risk for abuse but there will be ways to mitigate that.... |
|
if there's a chat room, it could be useful to post/cancel a chat with a command there (instead of filling the table/fields one-by-one). Something like: "buy 20 BSQ for 50USD Revolut" This also kind of gives notification for a new offer. |
|
Maybe I share as well my preliminary rough ideas about identity in the new model. The network will operate on a network node identity (for routing, peer management) which is not used for higher level communication. This identity (onion address) will have a medium lifetime (e.g. 1 month) before being renewed. It is mainly useful to find past peers for bootstrapping. Any higher level communication (offers) get its isolated address and key pairs, e.g. each offer has a different onion address and keys. There will be an identiy key as well which is under full control of the user. They can choose to keep them longterm for building up reputation but that likely comes with some level of decreased privacy. Or they can choose to not use it ay all so they appear always like a totally new user. Maybe there will be multipe such identities so users can selectively expose one identity in one context (e.g. for fiat trades) and another one for other contexts (e.g. altcoin trades or engaing in chat conversations). So this should serve as decentralized moderation model which will heavily depend on the costs of creating new identies. As said those are very rough ideas but I think those will help in many areas and play nicely into the social aspect (e.g. bootstapping by getting vouchers from friends). Of course the privacy protection will always stay in the center and those who do not want to use such identites need to pay via a monetary contribution. I fear in a perfect anonymous space certain features would never work as costs for abuse are zero, at least not if it scales up. |
|
Added date. Good idea for offers to automatically disappear after a week.
|
Would it make sense to somehow very easily "import" or post the account age from Bisq in your fiat buy offers? I mean, without building again Bisq in this simplified layer, which I understand it is not the point at all. (for secure tx, we already have the full featured Bisq app). For the spreadsheet initial version, maybe the account age could be posted in the column "Security contract" and then the traders would manage on their own how to verify it. |
|
This would require extra work in Bisq to export it as a text format and then to add a tool for verifying it (similar like a signaure verification tool). I would prefer to keep the scope limited for now. Once the trade board is integrated in Bisq it can be done there much easier, but externally its not that easy. |
|
Since real life is the best test, I thought that while we build something better we could play around with a Google Sheets. I know it's not the best for privacy, but I will delete it in a couple of months. Sisq order book 0.1 just testing Minimum viable product and iterate... Feel free to play around! |
|
A lot of curious users lurking and our first offer (by someone other than me)! We also had our first bit of vandalism 5 minutes in. That's part of the test I suppose! |
|
I'd like to offer another alternative, easier to implement and fulfill the same requirements imo, in the spirit of what was described here. In theory, I could take it upon myself to build lots of what is proposed here, but I'd need the help of a UX designer/or frontend developer (I can do that, but I'm not great at it), and it also depends on the budget. The proposal has three phases. Phase one: a decentralized message board for small tradings, with centralized control. This means one public key controls it, but the storage and access are decentralized. Phase two: add a basic reputation system. It's not mandatory, but I think (unofficial) reputation is part of what does the Keybase group successful. Phase three: integration into Bisq, but that's quite a big stage which I'm not going into now. I'll discuss only the components of the first phase here, there's no point in discussing further if you don't like it. ID: Let's begin with this because it influences a lot of the rest. I think the proposal here is too complicated for this phase. Also, there is a fully developed field of DIDs, and there is no reason to ignore that. My proposal? Use the current Keybase IDs if possible. It saves a lot of work. I need to look into how to integrate it into a webapp, but I know you can make a Keybase bot, so people could even add offers/report successful trades via commands in the Keybase channel. The bot would take those "commands" and adjust the website by them. Keybase IDs also let people already chat with each other, so it's the start of the social media we want to explore. If not, I'd look for existing DIDs, or even writing a browser extension that manages an ID for this app. As long as this is an independent app, I think using Bisq/Onion IDs might be too complicated, no? Reputation: In the second phase I propose to add a simple reputation system based on this ID. It would have a trusted kernel of people, and then others would gain a reputation based on any successful trade. Of course, it should also have a way to take a reputation from someone. UX: Are you set on this spreadsheet UX? If one goal is to see which UX fits this kind of small tradings with multiple options then a spreadsheet is very unflexible, and definitely not the preferred UX for modern apps. How about doing a webapp instead? It can still have a spreadsheet look, but with on-hover and other smart features to make it more usable. You can do something "fast" to React, and can modify it quickly to experiment with different UX and processes (after the board is already up), to see what fits best for users. If we want to be "whimsical", we could even choose a fun cypherpunk theme, like this. Functionality: I agree with most of what was written here. Personally, though I'd automatically remove offers that are more than X hours old (24 hours, 48 hours etc.). Technical settings: The way I see it, there are three "easy" options.
The good thing is that it's really easy to set and operate. They got a fantastic infrastructure, native daemon, proxies, extension, and gateways to access it. It also makes the person who operates the website (by a private key) anonymous (as long as he sends the updates to the network via Tor or something). However, the P2P is not anonymous, but if someone would want to keep their privacy while visiting the website, they could simply use the Tor browser. Generally, IPNS website got an "ugly" URL (a hash), but you can connect it to a decentralized name service (ENS, Handshake) to give it a URL that is easy to remember. It may be "slow" to access IPNS websites, I need to experiment with it if we decide to go with this option. But I'm sure we could find a way to make it resonable fast. |
|
Here is my current state of development: |
|
Just so everyone knows and this is tracked here, we have migrated the spreadsheet from Google onto a more private, secure and censorship resistant alternative called CryptPad that better lines up with Bisq. The spreadsheet has also been cleaned up a bit and a README section added (feedback on this would be good if any changes are needed). It is still fully open right now but the ability exists to add a password or even only allow users with an invite link to be able to make edits (Market makers) but allow all users to view offers. We can make these adjustments a bit later if we run into spam issues, although this is just a temporary solution until something gets built inside Bisq. The new link is here: https://cryptpad.fr/sheet/#/2/sheet/edit/tE42iuR--PZ3PsQOyayt9JFo/embed/ |
|
For updated on the progress on the P2P network work see https://github.com/chimp1984/misq/discussions/ and the keybase #misq-dev channel. |
|
I renamed the prototype repo to https://github.com/chimp1984/misq_prototype1 so discussions are found at: https://github.com/chimp1984/misq_prototype1/discussions Will continue to make weekly reports and dev call agenda and minutes here now. |
|
Weekly update 6.6.2021:
Next steps:
|
|
Agenda dev call 7.6.2021:
|
Might be a typo, but to clarify, the api would not know anything about the grpc server or webapp. It's the other way around: the grpc server and webapp would use the same api, and serve grpc clients (CLI) and web clients (REST/json) respectively. |
|
Yes, sorry was sloppy.... and also shows its not my domain ;-) |
|
Update: I worked on the basic misq build/module organization. I have also been working on a simpler way to use RE @chimp1984's I don't think we have to choose between grpc or web/rest, unless dev time is the only consideration. The server apis would not depend on any grpc or web libraries. Grpc services and a web app could run simultaneously, using the same api instances. There is no need to make grpc work with web clients; a web frwk like ratpack would do that instead -- unless dev time is the issue. |
|
Add-on to my update:
Here are the modules in order of dependencies: i2p and tor might be moved to their own repo once its more final. Just keep in the project as its more convenient for developing. Here is my WIP branch: https://github.com/chimp1984/misq/tree/chimp_prototype |
|
And here is a UML for the core domain objects. Just a rough and trivial sketch... |
If it is just re-using the jpackage mac signing params than it might not work. At least it didn't work for us. It might be that in that case the plugin cannot be used easily and you'll need a manual process as in the package.gradle file for Bisq. |
It might not. If it doesn't we could fork it and add what it needed to make it work , doing all the packaging tasks in java. Here are the mac os (signing) related Does it look like the OS X config params are missing something Bisq's |
|
Here is the first misq issue: |
|
Meeting minutes to todays dev call:
@cbeams joined us as well and we discussed the general potential use cases for the project like integrating it into personal box projects or providing a more general purpose API so other projects can integrate Bisq. We discussed the REST vs. GRPC API topic and cleared misunderstandings. We will provide both APIs and they are thin layers using the core API. We will add ratpack and the webapp module which @ghubstan had already in his prototype project. We discussed to make a public kickoff call to get a better understanding for Bisq contributors about the project. We discussed the strategy how to make PRs to the official repo and consider it still a bit too early but might start with small as stable considered parts which we be likely util classes etc. Other devs will fork from my repo and make PR to that until we get to a more stable code base. |
|
Here is the announcement for the kick-off call: |
The problem was not with those parameters (they are sufficient), but when we uploaded the signed binary for notarization it failed because of specific signing requirements that were not met, which we had to do manually. Maybe this is fixed in Java 16 OpenJDK already as we use Java 15 right now. |
|
But yes, in that case it would be good to fork and prepare a PR for the required changes for macOS to have a cleaner build file in the end. |
|
Update 13.6.2021
Had 2-3 days off because of the vaccine. |
|
Agenda dev call 14.6.2021:
|
|
Update @chimp1984 : #51 (comment) We discussed the PR policy and aim for 2 (ut)ACKs before merge. |
|
These two messages in current Bisq 1.7.0 are interesting and relevant to Misq... I imagine any multi-protocol message board would work a bit like this... showing ALL offers in the same offer book, but indicating which ones are compatible and allowing users to filter. This provides useful information, since most users would want to be using the most liquid and popular protocols and payment methods. It's also a good place to prompt new users to set up new payment methods or protocols. |
|
I dropped the idea to ship a MVP with the above defined scope but got lot of progress on the Network layer and have a similar MVP with a simple message board where users can post trade intents and a private chat section. I share here my current state, but don'e expect a nice UI, its just a prototype which allowed me to test the P2P network use cases with something more real. The P2P network feature set:
In the UI prototype I have implemented following use cases:
Beside that there is a network overview screen added with basic info about the network.
Here are some screenshots: |
|
As one can see in the RTT I2P seems to be faster than Tor |
|
Looks promising! 👍 But I'm not so sure about the ask/bid usage. On trading platforms they have a somewhat a different meaning and we probably want to use them in the 'real' offer book like that. Maybe use for the trade intents:
and in the postings table:
WDYT? |
|
Yes the user facing language is not decided yet. I tend to use ask/bid in the domain. There are cases where its not clear which one is the "main" currency and using the buy/sell or base and counter currency terminology will not work well. |
|
This is a really good start in introducing a more social aspect to Bisq. It encourages the Bisq community to stay connected and engaged during the trading process and should be very useful for first time Bisq traders as well as reputable traders. Just a few design considerations for those focusing on UX:
In addition to the use cases @chimp1984 has listed, I can take a look into a few subject areas. Research will help in:
This ensures that the messaging service is customised/designed to the Bisq’s user needs and adds to the more ‘human’ experience of the chat feature. Let me know if there’s anything else anyone would like me to look into regarding this. |
Description
Based on the idea proposed at bisq-network/proposals#330 and bisq-network/proposals#331 I would like to start with a minimal viable product for a shared messageboard for any type of offers which can be executed out of band and do not provide a standard security model but leave it to the traders to propose and negotiate that aspect.
To test the basic idea we can start with a super simple model in form of a shared spreadsheet. This helps us to learn from early feedback as well it extends the user base for Bisq and enables trade opportunities for small trades with lower or no security requirements, trade without having Bitcoin, instant trade,...
The used model has to work without requireing users to register (e.g. not Google account required).
In parallel we can start to build a new improved P2P network and a message board. Once a MVP is available we can add it to Bisq as add-on module. The user can decide to load that module and then have a button in the UI to open a new window which displays all those offers (or integrate more elegantly...).
To keep it separate from current p2p network comes with the benefit that it does not add risks to current network (spam) and its easier to integrate (does not require new message types in Bisq). And it allows to bootstrap the new network using the existing Bisq user base as well as test it in production with low risk (worst thing a message is not shown).
I have done some base prototyping already on that and I think I can get a basic MVP in about 1 month. After that the P2P module can be improved and again use that low-risk use case for testing it in production, which is a great benefit.
Another benefit of having an independent p2p network and message board stack is that other projects who need that functionality (e.g. Comit, Farcaster) might choose it as rather lightweight module for their needs.
We should provide also a version with a web frontend and anyone (e.g. via mobile) can browse those offers and get in touch with a potential trader. Once they want to trade with higher amounts and security they can use Bisq, so it helps to attract new users. There will be no fees for that so that will be attractice as well.
Rationale
We need to develop alternatives to the current Bisq trade protocol as it is challenged by high miner fees as well from new developments like atomic crosschain swaps and the current Bisq code base is not designed for a multi-protocol model, so adding new protocols or security models would require a lot of dev effort.
Why not use the current P2P network?
There are a few problems which could be all solved also in the current network with some effort but as its a life system, backward compatibility is a major effort and risks are high in case of new bugs. Also the scope has been bloated over time and the network does too much and is too tighly coupled with the application (not code-wise but conceptually).
The main improvements of the new network would be:
Criteria for delivery
Milestone 1:
Shared messageboard based on a spreadsheet model is accessible to users. It provides sufficient guidance for users to use it and understand the limitations, risks and that is not part of the official Bisq project but an out-of band project.
Milestone 2:
A MVP of the new P2P network with a messageboard is integrated into Bisq as optional feature. The P2P network might not have all its features like I2P support, PoW dos protection,DHT,... but it serves the use case to add, remove and display messages (offers, but can be anything).
It also requires a minimal UI for adding a new message which could be plain text or json initially, but to be able to compete at least with the spreadsheet version it should support some defined fields (asset, amounts, payment methods,...).
Thought this will not be a fully fledged and well designed UI for creating offers. The UX for getting that done well is outside of the scope of that milestone.
It will come with some basic dos protections so that attacks cannot cause CPU or memory overconsumption.
A minimal web based solution should be included as well.
Measures of success
Milestone 1:
Allows presentation, adding and removing of offers via a webpage.
Milestone 2:
Allows presentation, adding and removing of offers inside Bisq as well via a webpage.
Risks
Milestone 1:
As there is no protection against spam or other form of abuse it might need to be shut down anytime by the operator. In case illegal content is posted the operator need to remove it to not risk legal liability.
Milestone 2:
In case of abuse the protection mechanisms like pow against spam and a decentralized moderation system need to be added before it can be offered again.
In case of severe bugs the new p2p network could cause CPU or memory spikes and could effect quality of service for the normal Bisq app. To run it as independent process might reduce that risk, but it will be decided later how to integrate it.
For further rirsk reduction we can add a filter enty to deactive the module in case of severe problems.
Tasks
Milestone 1:
Milestone 2:
Estimates
Milestone 1:
Once a contributor has committed to lead that project they should add their estimation.
Milestone 2:
I would require a bit more time to define the scope and design of the P2P network but a rough estimation would be 10000-20000 USD. Once I have a more concrete concept I will add a definitive number.
The scope of the milestone is not the fully-featured P2P network layer, but it will likely include more as needed to fulfill the use case.
Notes
Anyone who is interested to lead the milestone 1 project should leave a message.
Any dev who is familiar with web development should get in touch with me.
The text was updated successfully, but these errors were encountered: