search

bisq-network / projects

@bisq-network project management
https://bisq.wiki/Project_management
9 stars 2 forks source link

Message board for multi-protocol project (working title Misq) #51

Open chimp1984 opened 3 years ago

chimp1984 commented 3 years ago

_This is a Bisq Network project. Please familiarize yourself with the project management process._

Description

Based on the idea proposed at https://github.com/bisq-network/proposals/issues/330 and https://github.com/bisq-network/proposals/issues/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.

mpolavieja commented 3 years ago

We should provide also a version as webpage and anyone (e.g. via mobile) can browse those offers and get in touch with a potential trader

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).

image

chimp1984 commented 3 years ago

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.

ripcurlx commented 3 years ago

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.

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 :wink:). 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).

flix1 commented 3 years ago

A first approximation to necessary fields:

image

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?

chimp1984 commented 3 years ago

@ripcurlx I am not so sure if that will happen that fast. But sure if it happens we have to add some access control. The idea with friends sharing tickets might be not bad and would play into the direction to add more "social features", and we could distribute those tickets via Bisq and could help to promote the new "feature". I think we have to see it clearly as an experiment, so to see/learn how long it takes before it gets abused will be an important result as well. I guess we have been too conservative in the past (e.g. not allowing traders to communicate as we feared that will be abused for social engineering).

flix1 commented 3 years ago

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:

Provide minimum Wiki content to explain the rules, limitations and risks Defined options and fields

chimp1984 commented 3 years ago

@flix1 I think we should drop the BUY/SELL terminology and use ASK/BID instead. BUY/SELL works if there is one side considered as money and one side as commodity (Buy BTC with EUR, buy ETH with BTC). But if we allow anything to anything that is lost. E.g. EUR <-> USD, ETH <-> XMR. So to make it more clear from the user perspective I think its better to use: I HAVE EUR and WANT USD or I BID EUR and ASK for USD. It matches also more the standard trade terms.

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.

chimp1984 commented 3 years ago

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.

flix1 commented 3 years ago

image

@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.

eyalron33 commented 3 years ago

How would the moderator know when an offer was "taken" and should be taken off the list?

chimp1984 commented 3 years ago

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....

eyalron33 commented 3 years ago

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".

chimp1984 commented 3 years ago

Here are the docs: https://bisq.wiki/Buy_BSQ#Buying_small_amounts There are 2 channels where traders can meet. I have not looked closer myself but seems it used and had zero problems so far

eyalron33 commented 3 years ago

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..

pazza83 commented 3 years ago

Hi @chimp1984 I think testing the ideas proposed in https://github.com/bisq-network/proposals/issues/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

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.

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 https://github.com/bisq-network/proposals/issues/330#issuecomment-826442088 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?

chimp1984 commented 3 years ago

@eyalron33

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.

Yes the spreadsheet is only a temporary quick and cheap test. The p2p network with a more sophisticated UI is the next step and that will be the base to the larger multi-protocol model. We can use that iterativ approach as low risk experimentation playground to work on the UX challenges how to present multiple protocols to users without confusing them.

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;)).

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.

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..

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.

chimp1984 commented 3 years ago

@pazza83

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)?

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. Beside that it comes with the UX challenges how to deal with many multiple types of trades and multiple secruity models. So it will help us to figure out early if that can work or there are massive problems. And further its an option to bootstrap the new P2P network without serious risks.

Would traders build up reputation on a burner account?

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.

If the message board became popular...

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 assume there are quite large Telegram OTC trade channels which work even in the present of scammers. But I am not experienced with that as well... so it will require more investigations and learning. Another approach can be to have friends networks, which are by default private publish/subsriber channels and you need to get an invite from a friend. That will automatically build up some sort of web of trust and that help to avoid abuse. Those coupons could be derived from Bisq security metrics like account age witness. But I think its too early to try to solve all potential problems now. We can declare it clearly as experiment which might get stopped any time if we see its not working, similar as we did with the keybase OTC channel.

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.

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.

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?

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 ;-).

However I might have misunderstood how the collateral aspect would work?

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). But maybe lets keep new security models out for the first step to limit the scope. No strong opinon here though.... What will be quickly requires is some good guidance for the user, what to take care of (risks), limitations, recommendations, and explainations for different models.

This UX challenge we can use as starting point to work on the overall biggest challenge of the Bisq 2.0 idea. I think the weakness here could be turned into a strength if we use the opportunity that people need to learn more about it as chance for providing education or enable social relationships. It likely happend in trader chats or key base that some confused newbie got help from an experienced Bitcoiner/Bisq user and created a positive social experience which you will never get a Uniswap or Coinbase. So thats what I mean with truning the weak point (that it requires more knowledge) to a strength.

chimp1984 commented 3 years ago

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.... The further we go that route to let users freely interact the more we enter the challenges of any social media platform ;-). Though we have some benefits over their options as we have conneced trust related data (account age witness) and financial aspects (bonds,...). Also the P2P network will come with some protection mechanisms (pow)....

eyalron33 commented 3 years ago

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.

chimp1984 commented 3 years ago

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). Those identities can serve for security (e.g. BSQ bonds), access control (e.g. vouchers for message boards entries), spam protection,... Areas with risks of abuse (message board, chats) might have a "report" feature and local ban lists. So you always can block an abusing users identity and/or report them to a group of moderators who can investigate and add them to their ban list. Any user can subscribe to such ban lists of moderators or just their own.

So this should serve as decentralized moderation model which will heavily depend on the costs of creating new identies. So users who prefer max. privacy might be excluded from those features or need to pay for access via a bond. E.g. if one cannot provide any reputation he need to use money as collateral instead.

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.

flix1 commented 3 years ago

Added date. Good idea for offers to automatically disappear after a week.

image

mpolavieja commented 3 years ago

the costs of creating new identies.

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.

chimp1984 commented 3 years ago

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.

flix1 commented 3 years ago

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!

flix1 commented 3 years ago

image

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!

eyalron33 commented 3 years ago

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.

  1. Use a platform. I'm not sure which one, I'm not a fan of platforms, but I could look into it.

  2. Run a website on a server. This makes it a completely classic website, but someone needs to operate this server.

  3. (my favorite): serve a website with a p2p network. I propose to use IPNS (not IPFS). You can think of IPNS as a website controlled by a private key, and served with a p2p network.

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.

chimp1984 commented 3 years ago

Here is my current state of development: https://github.com/chimp1984/misq/wiki https://github.com/chimp1984/misq

viperperidot commented 3 years ago

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/

chimp1984 commented 3 years ago

For updated on the progress on the P2P network work see https://github.com/chimp1984/misq/discussions/ and the keybase #misq-dev channel.

chimp1984 commented 3 years ago

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.

chimp1984 commented 3 years ago

Weekly update 6.6.2021:

Next steps:

chimp1984 commented 3 years ago

Agenda dev call 7.6.2021:

ghubstan commented 3 years ago
  • A grpc based API delivering json via ratpack server is considered atm

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.

chimp1984 commented 3 years ago

Yes, sorry was sloppy.... and also shows its not my domain ;-)

ghubstan commented 3 years ago

Update: I worked on the basic misq build/module organization.

I have also been working on a simpler way to use jpackage to build native package installers. The idea is to have custom gradle-plugins download and verify the jdk / jfx runtimes, then apply this jpackage wrapper plugin. The download plugins (java) just need download-urls, checksums, and extraction path specs in the configuration to work, then the jpackage plugin is applied. It looks like the jpackage plugin supports mac app signing, but I have not tried it yet.

RE @chimp1984's Agenda dev call 7.6.2021 comment:

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.

chimp1984 commented 3 years ago

Add-on to my update:

Here are the modules in order of dependencies:

common
i18n
persistence
wallets
security
network
identity
account
contract
offer
protocol
support
user
presentation
api
application
desktop
grpc

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

chimp1984 commented 3 years ago

And here is a UML for the core domain objects. Just a rough and trivial sketch... Screenshot 2021-06-06 at 15 25 47

ripcurlx commented 3 years ago

It looks like the jpackage plugin supports mac app signing, but I have not tried it yet.

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.

ghubstan commented 3 years ago

If it is just re-using the jpackage mac signing params than it might not work.

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 is the pulgin's gradle task with all the configurable properties: https://github.com/petr-panteleyev/jpackage-gradle-plugin/blob/master/src/main/java/org/panteleyev/jpackage/JPackageTask.java

Here are the mac os (signing) related jpackage params. They would be set in the build file's jpackage-plugin config:

      // OS X specific parameters    
      private String macPackageIdentifier;    
      private String macPackageName;    
      private String macPackageSigningPrefix;    
      private boolean macSign;    
      private String macSigningKeychain;    
      private String macSigningKeyUserName;
      if (isMac()) {
        addParameter(parameters, "--mac-package-identifier", macPackageIdentifier);            
        addParameter(parameters, "--mac-package-name", macPackageName);            
        addParameter(parameters, "--mac-package-signing-prefix", macPackageSigningPrefix);            
        addParameter(parameters, "--mac-sign", macSign);            
        addParameter(parameters, "--mac-signing-key-user-name", macSigningKeyUserName);            
        addFileParameter(parameters, "--mac-signing-keychain", macSigningKeychain);        
      }

Does it look like the OS X config params are missing something Bisq's desktop/package/package.gradle needs?

chimp1984 commented 3 years ago

Here is the first misq issue: https://github.com/bisq-network/misq/issues/2 Also descibes the app startup/setup design. If any dev is up for that please leave a comment.

chimp1984 commented 3 years ago

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.

chimp1984 commented 3 years ago

Here is the announcement for the kick-off call: https://github.com/bisq-network/bisq/discussions/5555

ripcurlx commented 3 years ago

If it is just re-using the jpackage mac signing params than it might not work.

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 is the pulgin's gradle task with all the configurable properties: https://github.com/petr-panteleyev/jpackage-gradle-plugin/blob/master/src/main/java/org/panteleyev/jpackage/JPackageTask.java

Here are the mac os (signing) related jpackage params. They would be set in the build file's jpackage-plugin config:

      // OS X specific parameters    
      private String macPackageIdentifier;    
      private String macPackageName;    
      private String macPackageSigningPrefix;    
      private boolean macSign;    
      private String macSigningKeychain;    
      private String macSigningKeyUserName;
      if (isMac()) {
        addParameter(parameters, "--mac-package-identifier", macPackageIdentifier);            
        addParameter(parameters, "--mac-package-name", macPackageName);            
        addParameter(parameters, "--mac-package-signing-prefix", macPackageSigningPrefix);            
        addParameter(parameters, "--mac-sign", macSign);            
        addParameter(parameters, "--mac-signing-key-user-name", macSigningKeyUserName);            
        addFileParameter(parameters, "--mac-signing-keychain", macSigningKeychain);        
      }

Does it look like the OS X config params are missing something Bisq's desktop/package/package.gradle needs?

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.

ripcurlx commented 3 years ago

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.

chimp1984 commented 3 years ago

Update 13.6.2021

Had 2-3 days off because of the vaccine.

chimp1984 commented 3 years ago

Agenda dev call 14.6.2021:

chimp1984 commented 3 years ago

Update @chimp1984 : https://github.com/bisq-network/projects/issues/51#issuecomment-860286471 Update @jmacxx: He worked on Bisq that week, but will switch back to Misq that week working on the wallets integration project. Update @ghubstan : He also worked on Bisq that week. Will switch back mid of the week probably. he will have a look to the build/ repo related tasks (get a CI setup, add Codacy) and will have a look to the json serialisation issue in the web module of @chimp1984's prototype branch. Update @stejbac : He did not had time to work on Misq that week but will continue that week and will review the PR with the security package.

We discussed the PR policy and aim for 2 (ut)ACKs before merge. We did not cover the RX version issue. Will get discussed next week.

flix1 commented 3 years ago

image

image

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.

chimp1984 commented 2 years ago

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. It would require much more work to make that a real user facing product and I consier other work as higher priority (e.g. work on the overall domain).

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:

Screenshot 2022-01-16 at 19 04 11 Screenshot 2022-01-16 at 19 16 15 Screenshot 2022-01-16 at 19 16 29 Screenshot 2022-01-16 at 19 57 24 Screenshot 2022-01-16 at 19 57 29
chimp1984 commented 2 years ago

As one can see in the RTT I2P seems to be faster than Tor