Skip to content
Snippets Groups Projects

recanman bitejo rewrite and expansion proposal

Closed recanman requested to merge recanman/ccs-proposals:recanman-monero-jobs-website into master
4 unresolved threads
layout: fr
title: Rewrite and expansion of Bitejo software suite
author: recanman
date: July 29, 2023
amount: 45
milestones:
  - name: Month 1 (Begin rewrite, backend and APIs) (80 hours)
    funds: 10 XMR
    done:
    status: unfinished
  - name: Month 2 (Complete the first draft of the backend and APIs) (80 hours)
    funds: 10 XMR
    done:
    status: unfinished
  - name: Month 3 (Integrate frontend) (80 hours)
    funds: 10 XMR
    done:
    status: unfinished
  - name: Month 4 (Final touches and launch, maintenance for 1 year)
    funds: 15 XMR
    done:
    status: unfinished
payouts:
  - date:
    amount:
  - date:
    amount:
  - date:
    amount:
  - date:
    amount:

I am proposing to rewrite the Bitejo web application suite.

Who

I am recanman, an ambitious self-taught full-stack developer with experience in many languages and fields. I have been involved in the computer science field for nearly a decade. You can contact me at @recanman:agoradesk.com, and there I can provide a PDF with my resume on request. I have a couple free software projects on my GitHub profile.

I have been involved with the Monero community for a little more than six months, and since then, I have learned an abundance about privacy, fungibility, free software, how cryptocurrency works, and much more. I am currently the writer of The Monero Standard, published by LocalMonero.

I have also localized websites in Arabic, including the LocalMonero and AgoraDesk websites.

This is my first CCS proposal, and I am excited to take your feedback on anything that should be changed.

What

Here is a basic description of what I am proposing to do over the next six months:

  1. Rewrite the Bitejo web application suite, exposing APIs and increasing the security and privacy.
  2. Host the website (For as long as I can, at minimum two years. If at any point I can no longer host the website, I will hand it over to a trusted individual in the Monero community).

Why

Rewrite

The original proposal (see edits) was for a completely new service dedicated to jobs. I was informed of the Bitejo web application suite. Unfortunately, it is written in messy, procedural PHP, and is unstable ("Warning: This code is amateur-level, messy and not fully tested. Some parts should probably be refactored or rewritten from scratch. This is a hobbyist project that was casually under development since late 2018 and released in 2021."). Many parts of Bitejo are unorganized, a big one being authentication, privacy, and security. While the website does not utilize client-side JavaScript, it still needs an email address for management of listings, which can be remade into a central user authentication system. While chats are encrypted with AES-256 properly, the keys that are used (I have confirmed with the owner that the keys are different from the public instance) are stored in the source code, which are one of the many bad practices present in the code. A proper and secure platform needs to exist in order to replace the use of privacy-violating services, and to encourage the use of Monero.

How

I have vast backend experience is in Node.js, so I have decided to propose building this website with the following technologies:

  • MySQL (database)
  • Express (web server)
  • Nunjucks (view renderer)
  • Node.js (backend language)
  • Redis (caching)
  • Monero (currency)

All of the website's code will be completely open source and free software, and I encourage others to contribute to the project.

The website will not need JavaScript enabled on the client to operate in order to preserve the privacy of the users. I will implement encryption where-ever I can and minimize plaintext stored in the database.

At the end, there will be the following services implemented in the Bitejo web application suite:

Rewritten:

  1. A marketplace service (Craigslist).
  2. A fundraising service (GoFundMe).
  3. Digital assets service (Shopify).

There will be a GitHub repository as a mirror to my private Gitea server on https://github.com/recanman/monero.jobs.

Proposal

I propose to work 80 hours each month, equating to 20 hours per week. This ends up with a total of 0.15 XMR per hour, which is around $22.87 USD per hour, using the price of $152.47 USD, calculated based on the exponential 14-day moving average from Yahoo Finance.

According to salary.com, the median software developer hourly wage is $37 USD, which is close to what I am proposing. If the monthly milestone is not met due to a dip in the hours worked per week, the milestone completion will be at the completion of the hours listed for that month.

If I do not complete the website by December 31, 2023, the proposal shall be considered expired, and the funds raised for this proposal can be put back into the Monero General Fund or used to fund other proposals.

Total: 45 XMR

Edited by recanman

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • recanman changed the description

    changed the description

  • recanman added 1 commit

    added 1 commit

    Compare with previous version

  • recanman changed title from recanman monero jobs website proposal to recanman bitejo rewrite and expansion proposal

    changed title from recanman monero jobs website proposal to recanman bitejo rewrite and expansion proposal

  • recanman changed the description

    changed the description

  • recanman added 1 commit

    added 1 commit

    • 9bb167c7 - decrease price by 20 XMR, change proposal name

    Compare with previous version

  • +1 I support this proposal 100%. Sadly I can't contribute to funding or development (this would be a solo project for Recanman). My version of Bitejo would continue as a hobbyist PHP project. Recanman's Node.js rewrite (with a different name and logo) has the potential to become a modern, popular Monero marketplace and contribute to building local and global Monero circular economies. Node.js is more popular than procedural PHP and this rewrite would make it easier for devs to develop new features, as well as significantly improve the existing codebase (which is currently messy and outdated in parts).

    • I would like to echo the opinion (which i agree with) that this is not a technical problem that needs to be solved 'yet'. We have functional websites such as:

      At this point in time i feel the main issue is marketing - literally just getting people to use the products on a widespread scale, so i wouldn't support a full re-write at this point in time.

      Some problems you note about bitejo:

      still needs an email address for management of listings

      not the end of the world

      While chats are encrypted with AES-256 properly, the keys that are used [...] are stored in the source code

      what are we building here? what is the threat model? what opsec do we need for communicating on a clearnet market site? are we rewriting silkroad v1.0 in 2023 to sell paintings and honey? what about code / security audits? who will fund them? (i notice an escrow / custodial wallet / fees are involved)

      For privacy, users should manually encrypt sensitive messages with the sellers PGP key (due diligence to confirm it's correct) and not trust the service they're using to do it for them.

      Apologies for this comment going off into several tangents / not asking a specific question. A full re-write is not what i had in mind when suggesting improving existing services.

    • It's understandable to prioritize marketing over a full rewrite if the existing websites already serve the intended purpose. While I do not agree that the websites provide all of the functionality that I am proposing, it doesn't necessarily mean that the website can't or shouldn't be improved, as it drastically needs to be.

      The escrow will not use any advanced functionality (like multisig), and will go through heavy testing. About it being custodial, escrow is optional. Non-custodial is still allowed.

      On your point about OPSec, this site is aimed to allow users who want to provide the minimum form of identification in order to be able to transact within Monero's economy. Even providing an email address can be a reason why one would decide not to use the site.

      Disclaimer: I do not endorse the use of dark net markets, nor have I ever visited or used them.

      SilkRoad (and other DNMs) are only for the purchase and selling of items. As I mentioned in the proposal, this is meant to be a suite of services that a user with one account on the site can use. With providing multiple services under one user account, a user can build a reputation, and will use the site for many purposes.

      A rewrite would allow for more efficient code maintenance and upgrades, reducing the overall cost of development and maintenance. The current code is an unmaintainable mess and is unstable. The rewrite will add new features and functionality to the website, making it more attractive to potential users. Using Bitejo's design as a minimum, a rewrite will also add on to the site's usefulness by providing an all-in-one solution.

      Ultimately, the decision to rewrite the website should be based on a cost-benefit analysis of the potential benefits versus the cost and effort of the rewrite.

      While marketing is certainly important, a website that provides a poor user experience or lacks relevant features will struggle to attract and retain users no matter how aggressively marketed it is.

      Edited by recanman
    • Please register or sign in to reply
    • General reminder to people looking at this proposal that someone is working on a decentralized Monero marketplace right now.

    • I did look at that, and that is a great project, and I would like to present my point through a comparison between Bisq, a peer-to-peer exchange network and LocalMonero. Bisq is peer-to-peer, and requires software to be downloaded. Misconfigurations can harm the users' privacy. This will exclude many users who do not have the knowledge to run and troubleshoot the software. LocalMonero is accessed with a web browser, and is very simple to use for people who are new to the currency.

    • There is also a proof of concept @ https://github.com/creating2morrow/neveko "full-stack privacy application with gpg messaging, monero multisig and built-in i2p marketplace"

    • Please register or sign in to reply
  • I would like to point out, on top of the other projects being created, I am currently working with Doug of MoneroTalk on a project like this.

    We are attempting at creating something sustainable, that can stay on its own without community funding, via escrow fees and or post/sale fees (Would be reasonable and not super high)

    It would have PGP encrypted messaging, Multi-sig escrow (Which we already have an untested implementation for) Listings for product buy/selling aswell as hiring/looking to hire (specific "Buy XMR" or "Spend XMR" categories, profiles etc. A sort of all-in-one. We have an MVP that we are starting to work on which will be not as ideal in terms of quality, but can get us started, and in the future we'd probably hire somebody like you to re-write a lot of it.

    Not trying to steal anyone's thunder, just wanted to put that out there, before the community funds a huge project, Doug wanted to let people know that we are already working on something similar to this, but without community funding.

    Edited by tuxsudo
  • just adding that there is also https://gitlab.com/beardog/merkato which had a unique Web Of Trust feature people where interested in after their unsuccessful CCS !340 (closed).

    OpenBazaar raised over $9million and still failed.

    Marketplace related things on the CCS seem to be a no-go (see forgotsudo above). Escrow means legal/security issues.

    Edited by plowsoff
    • One of the planned features for Bitejo was federation. If you plan to rewrite it, adding this feature to your roadmap would be nice.

      Smaller marketplaces are failing due to network effects: when service is used only by a small number of enthusiasts, its utility is near zero. Of course, UX and marketing are also important, but these factors are secondary.

      The solution to this problem is to connect users across different marketplaces. Even better, you can connect them to an existing network such as Fediverse, that would create more opportunities for promotion.

      Federated marketplace is a novel concept, but ActivityPub (the protocol powering the Fediverse) is very flexible and can be extended to accommodate this use case. Anyone with a web development background can work on it, no advanced knowledge required. The protocol is lightweight; a well-designed ActivityPub node can run literally anywhere. Businesses can run their own servers to maximize sovereignity. You also get a familiar user experience. Federation over Tor and I2P is possible too, so those who want peer to peer anonymous marketplaces can use the same protocol.

      Maybe someday people from monero.town will be able to visit a shop on Bitejo without leaving their site.

      That being said, there are many challenges ahead and I don't think it is possible to build a federated marketplace in 6 months. A more reasonable estimate is 1-2 years.

    • There are already a couple projects that work with federation, and I feel that this may be out of the scope of the CCS. I could possibly create another CCS implementing federation after this one.

    • I'd appreciate an example of such project. As far as I know, no one is building a federated marketplace that could support Monero. There is a number of p2p marketplaces in development, but all of them are using their own custom protocols, increasing the fragmentation even further.

      Anyway, including federation into next CCS would also be great. Hopefully by that time there will be at least one project which prioritizes interoperability (I'm working on that).

    • You are correct. I was referencing to federated marketplaces that were peer-to-peer, not necessarily using standardized protocols. I am experienced with the ActivityPub protocol and I am willing to implement your idea in a separate CCS. It would take me another four to six months in itself to implement federation in the marketplace.

    • Please register or sign in to reply
  • recanman changed the description

    changed the description

  • recanman added 1 commit

    added 1 commit

    Compare with previous version

    • I really like the Kuno fundraiser, I think the site look and feel is spot on, much better than xmrstarter (the only other Monero fundraising tool I'm aware of). Currently, when you donate to a fundraiser, the site may or may not record your donation. The recipient always gets the XMR, just might not be shown on Kuno. The only sure way of seeing your xmr added to the total raised is if you add a comment with a TX ID and TX Key. Will this behavior remain after the rewrite? Or can that be improved, to not sometimes require that extra step from donors? In a chat with Anarkio, he mentioned the need for a local full node + extra storage to reduce risk of missing transactions.

    • thank you for raising this point @FiatDemise , having done some work on fundraising front ends myself i feel i can answer this. for donations to appear automatically, every fund raiser wallet has to be loaded and constantly syncing which increases resources (2GB of ram per wallet initially). alot of the work is duplicated / a waste of effort - this is where monero-lws server comes in for keeping many wallets synced (think of RINO/MyMonero).

      Instead of using monero-lws, xmmrstarter uses the monero python library to scan blocks for outputs belonging to a specific address+viewkey combination (pre-view tags, i was able to scan about 400 blocks of 30~ tx's in under 2 minutes. Python is slow , so when using the 'generic xmr scanner' written in C++ the 400 number reached several thousand+ addresses (which is the same tech/methods that monero-lws uses) - so on an 'ok' vps - xmrstarter could handle 400 ish active fund raisers which is more than enough. switching to monero-lws backend would enable thousands of active fundraisers / which update each time funds are received in a block.

      Kunos method uses the lowest resources / spec requirements for the server.

      Edited by plowsoff
    • @recanman , do you agree with @plowsofff 's comment about how to improve donations appearing automatically for the fundraiser? Do you think those are changes you could make? And, would you be open to splitting the fundraiser portion off into its own proposal? I would donate to that.

    • Yes, this is one of the changes I am planning to make. If the proposal gets approved, I have a list of improvements that I will show, allowing contributions from the community. I have already planned (and implemented as a PoC in my own time) the use monero-lws in Bitejo Kuno.

      In terms of splitting the fundraiser portion into a separate CCS, I don't feel that would be appropriate. I believe that the three implemented web applications (fundraiser, marketplace, digital marketplace) should be all rewritten in one go.

      This is my first proposal, and it may seem a little large to sum. Plowsoff has suggested for me to take over maintenance for the monerophp library. If that one gets merged, the rewrite will be done in my own time as a hobby project, and will be released under a different name.

      Edited by recanman
    • Please register or sign in to reply
  • Contributor

    It goes without saying that the quality of your essay is sufficient; but, I believed that seeing professional images and videos together would be a significant improvement. On globle, you will find articles and photographs pertaining to these issues; thus, I would appreciate it if you would visit and provide your feedback.

  • closed

  • I am closing this temporarily in anticipation of merging !402 (merged).

    Edited by recanman
Please register or sign in to reply
Loading