memo | desktop | |
---|---|---|
2 | 2 | |
0 | 5 | |
- | - | |
10.0 | 4.6 | |
over 5 years ago | 4 days ago | |
Go | JavaScript | |
MIT License | GNU General Public License v3.0 or later |
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
memo
Posts with mentions or reviews of memo.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-06-10.
desktop
Posts with mentions or reviews of desktop.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2022-11-26.
-
Bitcoin Cash Tinkering "We’d rather BCH stopped breaking the protocol and focused on scaling instead so we can keep using it."
Here's a summary of arguments I've seen in this thread and my responses to them: 1. > If you want to increase OP\_RETURN, create a CHIP I don't think there should be a CHIP process. No new rules should be added. The only changes that should be made are removing unnecessary rules that BTC created. And just like miners accept low fee transactions or mempool chains however long they want, they should freely adjust all limits. 2. > You say you don't want any changes but you want to increase OP\_RETURN size See response #1 3. > It's not voting, "it's consensus" Call it what you want 4. > BCH is scaling, they removed the chain limit Yes this is a huge win. Give credit where it's due. 5. > This guy is a BSV parrot I support forking if people want to try out different ideas. That doesn't mean the two forks have to go to war afterward, or that everything another fork does is bad. I'm also happy ABC is doing their thing with eCash now. 6. > This guy is a paid troll Not even sure why I'm responding to this. But ya sure, I build software that operates on BCH while getting paid to bash it... 7. > Nothing has been broken Must not be developing on BCH. To be fair things were pretty good for awhile with ABC gone, but that seems to be changing. 8. > Why is this guy complaining about centralization, Memo is centralized website We've been publicly working on an open-source version of Memo for over a year now: https://github.com/memocash/desktop 9. > If you want a frozen protocol build on BTC or BSV This is basic sentiment I've gotten from BCH over the years when I speak out about changes. "If you don't like it, leave." Message received. 10. > There's a plan to increase OP\_RETURN from 220 bytes to X bytes (still 1/1000th of a floppy disk usually) How about miners adjust limits on their own instead of holding elections for their rights
What are some alternatives?
When comparing memo and desktop you can also consider the following projects:
chip-bcmr - CHIP: Bitcoin Cash Metadata Registries
bch-vm-limits - By fixing poorly-targeted limits, we can make Bitcoin Cash contracts more powerful (without increasing validation costs).
urbit - An operating function
diaspora* - A privacy-aware, distributed, open source social network.