[bisq-network/projects] Message board for multi-protocol project (working title Misq) (#51)

[eyalron33]

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](https://github.com/bisq-network/projects/issues/51#issuecomment-828063783) 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](https://arwes.dev/).

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/projects/issues/51#issuecomment-830086442
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20210430/cf9a26fb/attachment.htm>