nanowallet
orbitdb
Our great sponsors
nanowallet | orbitdb | |
---|---|---|
10 | 32 | |
5 | 8,114 | |
- | 0.9% | |
3.6 | 9.3 | |
about 3 years ago | 7 days ago | |
JavaScript | JavaScript | |
- | MIT License |
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.
nanowallet
-
New to researching Nano, what the elevator pitch?
I'm hoping to do just that, build a test mobile wallet, sometime in the near future (https://github.com/mistakia/nanowallet)
-
Does Nano currently have any mixer service?
I was planning on testing this out sometime in the future by building it into a privacy-minded mobile wallet: https://github.com/mistakia/nanowallet
-
What is the plan for slow nodes bogging down the network?
Practically speaking, most wallet applications are dependent on a node to know the state of the ledger. The natrium wallet is connected to the natrium node. The nault wallet randomly chooses a node from a pool of nodes but can be configured to connect to any node. It is possible to design a wallet that doesn't rely on a node and instead connects directly to the network and maintains its own perspective on the state of the ledger locally. I hope to make a proof of concept of that at some point in the near future. This is how the nanollet wallet worked.
- Don't rush mass adoption
- What project, website or software is the nano community in dire need of but none exist?
-
Does a Nano privacy solution exists?
I know u/t3rr0r will be working on a privacy-focused wallet similar to what Samourai does for BTC. You can see a proof of concept here: https://github.com/mistakia/nanowallet
- Is Anyone Working On Adding Privacy to NANO?
-
What are NANO’s flaws?
Nano wallets can have multiple addresses as well. Nothing about the nano network limits a user or wallet developer to using one account/address, it is a choice. This is an area that needs more development as nano privacy wallets can become much more friendly, which is why I started this experiment.
-
Nano.Community, a follow-up on building OSS infrastructure for the nano community
Privacy focused mobile wallet — https://github.com/mistakia/nanowallet/
-
some thoughts and a few nano projects
Nano has an interesting advantage to explore layer two and wallet based privacy solutions given its lack of fees and ease of making transactions. I've started working on a wallet as a testing bed for these strategies. I'm aware of Nanofusion and other trustless mixing strategies for other pseudonomous projects (coinjoin and cashfusion). Please share any strategies and ideas on privacy solutions to avoid reinventing the wheel.
orbitdb
- OrbitDB reaches version 1.0 after 8 years of development
-
Open source P2P alternative to Slack and Discord built on Tor and IPFS
OrbitDB is not well-funded, but there's fresh work happening recently by some dedicated volunteers: https://github.com/orbitdb/orbitdb/commits/main
- Current Progress of IPFS
-
orbit-db VS db3 - a user suggested alternative
2 projects | 15 Jan 2023
- Jack Dorsey texts Elon Musk (March 26, 2022)
- Decentralised public immutable database
-
Ask HN: Is there a descentralized DB with a simple social conflict resolution?
I've been thinking it might be practical to build a simple decentralized database, where agents just know each other, so conflict resolution does not need to be so strong and can rely on the social layer.
I think this applies to most databases, but I'm particularly thinking of internal enterprise databases, some social networks, any federated database system, and different devices of a single user
I'm thinking of this features:
1- Append-only?, full history of operations. Deletes / edits do not remove data, they only modify the "active state"
2- Agents are public keys or similar (DIDs?)
3- Operations are signed, and receivers verify if operation is valid, and sender is allowed
4- Operations form a Merkel-DAG (similar to git, they link to the tips of current "active state", like a commit/merge in git)
So far I think I've basically described [OrbitDB](https://github.com/orbitdb/orbit-db)
Consensus is where things get real hard, [OrbitDb seems to use a last-write-wins CRDT](https://news.ycombinator.com/item?id=22920204), and although I don't know the details of orbitDb, I think for many simple use-cases, conflicts can just be resolved on the social layer. But I think we need to provide agents with good tools to resolve conflicts
I'll try my best here with some ideas:
- When merging, we can order operations by their timestamp, if operations enter conflict, raise it to the conflicting agents, or someone with permission to solve them.
If an agent makes public an operation that forks its own history, mark agent as malicious or compromised, alert other agents, this needs resolution on the social layer, you have proof of misconduct, an agent has signed diverging operations
Any operation becomes fully settled if you have proof that all agents of your system have referenced it directly or indirectly through newer operations.
Timestamps can be upgraded by using @opentimestamps to get proof that an operation existed at time X (prevents creation of operations in hindsight). Though this does not prove operation has been made public
-
How to make a crowdsourced distributed metadata database?
Both use OrbitDB: Peer-to-Peer Databases for the Decentralized Web. JavaScript. MIT license. repo
-
Release: New features for Nalli
I think a wallet-agnostic memo solution is definitely the way. Having wallets that end up (partly) incompatible is only gonna hurt the UX. Maybe a decentralised DB solution like OrbitDB or GunDB can be the best way forward, although I haven't dove deeply into the docs yet.
-
Building a decentralized database
Checkout this https://github.com/orbitdb/orbit-db peer-to-peer database for the decentralized Web.