Stay on topic:

  • This thread is only for comments discussing the uncertainties, shortcomings, and concerns some may have about Monero.
  • NOT the positive aspects of it.
  • Discussion can relate to the technology itself or its economics.
  • Talk about community and price is not wanted, but some discussion about it maybe allowed if it relates well.
  • Be as respectful and nice as possible. This discussion has potential to be more emotionally charged as it may bring up issues that are extremely upsetting: many people are not only financially but emotionally invested in the ideas and tools around Monero.

How it works:

  • Post your concerns about Monero in reply to this thread.
  • If you can address these concerns, or add further details to them – reply to that comment. This will make it easily sort-able.
  • Upvote the comments that are the most valid criticisms of it that have few or no real honest solutions/answers to them.
  • The comment that mentions the biggest problems of Monero should have the most karma.

Previous:


The first principle is that you must not fool yourself — and you are the easiest person to fool.

  • Anark Karabey@monero.townOP
    link
    fedilink
    arrow-up
    4
    ·
    3 months ago

    I think the rift between haveno devs and the haveno-reto devs is causing some project management issues. One such example that I get direct exposure is around adding a flatpak and AppImage packaging for Haveno(-Reto) and another is around how (or should?) should the users be able to switch between mainnet providers.

    For the example of the first one read down from this message: https://github.com/haveno-dex/haveno/issues/270#issuecomment-2294807880

    And for the example of the second one, read down this issue: https://github.com/haveno-dex/haveno/issues/931

    There is a friction in trying to coordinate and contribute to the developers working on different (albeit quite similar) repos (in the case of the original Haveno repo and the -Reto repo). This friction in comms and contribution is causing delays in introducing software distribution packages such as AppImage and Flatpaks, which hinders (especially for TailsOS and Qubes-Whonix users) the onboarding of the new users, and decentralizing Monero’s liquidity.

    • xmr_unlimited@monero.town
      link
      fedilink
      English
      arrow-up
      2
      ·
      3 months ago

      Is appimage or flatpak actually needed? Devs probably have things higher priority. You can “install” the .deb on most Linux systems simply by extracting the needful and running the binary. You may need to download the java runtime to run.

        • xmr_unlimited@monero.town
          link
          fedilink
          English
          arrow-up
          1
          ·
          3 months ago

          People have has success running on both of those, so I’m really confused why its absolutely necessary. I say again, you literally can unpack the .deb contents to run tbe executable.

          • Anark Karabey@monero.townOP
            link
            fedilink
            arrow-up
            2
            ·
            edit-2
            3 months ago

            people have success

            Which people? Probably technically-minded, and over-determined people, yes. But do we want only such people have access to Haveno? Absolutely not. People who are only able to burn TailsOS onto a USB should also be able to hop-onto using Haveno and contribute to Monero"s distributed liquidity.

            you literally can

            No I literally cannot! (maybe). AppImage model of running a program is exactly the same as running an exe file. Download, allow executable, and run. Most newcomers easily get disheartened when they read that they need to unzip a deb file or something.

            • nihilist@monero.town
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              2 months ago

              haveno is in early stages anyway, but yea the more noob friendly it becomes, the better. Something is “”“hard”“” to install when you do not explain how to install it properly.

              Currently there’s a way to install it on every OS, that’s good enough for now. Also keep in mind that there aren’t 20 dedicated developers working on haveno fulltime, you can’t have everything at once with a small team of developers

    • jet@hackertalks.com
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 months ago

      True, but this is the price you pay for the developers being totally independent from network operators.

      Their incentives are not totally aligned, and we get friction

  • Bobr@lemmy.libertarianfellowship.org
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    3 months ago

    If we look at the funded CCS proposals https://ccs.getmonero.org/work-in-progress/, a lot of the recently funded proposals have very few donors, while the amount of money donated is quite big, which means that they are extremely generously funded by a very small group of people (sometimes just 1 person!).

    1. Do we know who is funding the proposals? (I know we cannot answer this by looking at the blockchain due to the privacy features of XMR, but maybe there are some accepted theories in the community where funds are coming from?).
    2. What happens if those few people stop their donations?
    • g2devi@feddit.nl
      link
      fedilink
      arrow-up
      2
      ·
      3 months ago

      Fortunately, you’re reading the numbers wrong. Yes, some projects have 1-3 projects. Those projects tend to be side projects (e.g. Revuo, web site maintenance, etc) and are likely founded mostly from wallet providers and Monero service providers since it helps spread information that helps the ecosystem. I know Cakewallet has funded a few of these. The really important projects have 5-70 contributors. If donations stop, then some people would keep working on it because Monero is important, but they wouldn’t be able to spend very much time on it so progress would be incredibly slow.