(hi seph, hope all’s well) — i did exactly this with Redwood and showcased it multiple times during Braid meetings. alas, nobody was very interested in trying to push it forward
... _what_? i don't think you parsed my comment correctly at all
to address the part of your comment that doesn't make my head spin: only very occasionally do i see senior Go developers import 3rd party libraries. i'm just speaking from my experience
this is a little too stoic a take with respect to a tool that very unserious people building things for serious but non-technical people use on a daily basis. i think we should strive for more. npm can continue to exist in its very libertarian form, but perhaps there's room for something that cares a bit more about caution
if you've been duped into importing a package which has been broadly deemed as spam (but you're not looped into the public conversation about that fact enough to realize it), wouldn't "breaking the build" be a good way to get you to realize your folly and avoid the trap?
it's language-cultural. to "publish a package" in Go simply means having a public git repository. and yet, nobody who writes Go imports packages. it's well-understood that if you can't write something like leftpad (or many other JS packages) yourself in your own codebase in a few lines, you're an absolute nonce. Javascript developers on the other hand tend to skew towards the juniors in our broader ecosystem, and they seek easy and quick prestige, which leads to "star farming"/"download farming"
i've built tons of very intricate payments systems over the past 10 years and i honestly have no idea how "payments engineer" is even worthy of a distinct job title. it's a thing people do in the course of building products. ridiculous
grapevine knowledge, but i have been told (and credibly, i think, given how adaptive humans are, and how they adapt for very specific parameters while devaluing others) that many homeless will go to great lengths to seek out new locales that seem willing to help sustain their needs without requiring wholesale change of their lifestyles. some people do indeed prefer it (or at least fear the alternative, i.e. “proper” integration into society and all that comes with that), as much as some people on this website cannot fathom that
while important, the fiat currency is a second-order issue, imho. the root is self-serving corruption facilitated by an intricate apparatus based on bureaucratic capture. to even appear as a choice on the ballot, one must either be part and parcel of this widespread corruption, or one must take the system by surprise with vast amounts of money and bluster (trump trump something something, fat lot of good that did, though). one of the biggest issues we have is that so much “shadow money” is allowed to influence politics. if the government was originally supposed to be a “check and balance” against accumulation of corporate power against regular people, phenomena like Citizens United et al have guaranteed the undoing of that guardianship. it is a society of grift now, through and through. and of course, being adaptive creatures, we learn from example, and we learn from our enemies, so anyone who once played the “good guy” role is stooping as low as his opponent now. surveying the political landscape, it’s often hard to find anyone spending more time trying to solve problems as opposed to maximizing instagram likes and chances for reelection
NB: there’s that whole discourse about “how are you all multi-millionaires when the pay for senator/representative is at most a few hundred thousand a year?”
“just noting” that this has no relevance to a sober and objective review of the points made within. i sometimes think that we’re lucky we still have two sides of the aisle in this country. i constantly think we ought to aspire to more
Any old timers here in the thread, please email me at [email protected] — I’m building a new company doing both consulting and internal product development and have always loved working with older, more experienced folks. We’re looking for tech leads, technical project managers, and anyone who has the ability to take strong ownership.
(FYI, that’s a burner email— I’ll reply from a different one)
I made Redwood, a general purpose p2p/distributed database (and blob store) with pluggable merge algorithms (including some cool CRDTs, like what @josephg is working on).
Oh, hey there, Coventry :)
I’d be curious to know the same, as well as to hear a comparison between Algorand and:
1) recent work on aBFT protocols, many of which don’t seem to require any kind of staking, and...
2) Chainlink’s off-chain aggregation protocol’s consensys mechanism
Redwood is a decentralized database providing a data model that's much like a Redux state tree. One of the fundamental design goals was to better harmonize how data is handled on frontend and backend layers.
It's also:
- syncable/offline-capable, thanks to a CRDT system
- able to serve as a standalone Git backend
- embeddable into Go applications
- immutable, in a blockchain-y sense, due to its append-only ledger
There are some demos in the Github repo:
- A real-time collaborative text editor
- A chat application
- Git integration
- A video streaming application (still improving performance here, but it's functional)
It's pretty alpha still, but feedback and contributions from anyone interested would be very welcome.
A few projects I'm involved with that might be worth sharing here:
- Redwood (https://github.com/brynbellomy/redwood), a realtime, p2p database. Data is structured in state trees that evolve over time. Merge algorithms are configurable at any point in a given state tree, but the default is a CRDT algorithm called "sync9".
- Braid (https://github.com/braid-work and https://braid.news), a draft IETF spec that specifies certain extensions to HTTP that make it much easier to build systems like Redwood. The Braid spec is under active development on Github, and we welcome input from anyone interested in the idea.
- Axon (http://axon.science and https://github.com/AxonNetwork), marketed as a platform for making it easier to collaborate on scientific research, but under the hood, it's basically just some extensions to git that allow you push commits over a peer-to-peer network bound together by a DHT.
I would also highly recommend getting involved in the Internet Archive's DWeb meetups and conferences, where you'll find hundreds of people interested in solving exactly these kinds of problems.
Sure! Nailing down a robust security model is a major goal for Redwood. There are currently a few different mechanisms, some already partially built, and others still in the research stage.
For what it's worth, I have a silly side project goal of reimplementing Bitcoin on top of Redwood, just to prove it can provide the same (general) security guarantees. Not sure I'll get around to that any time soon, though :)
Anyway, here's what we do:
1. Users are identified by a public/private keypair (actually using Ethereum's implementation at the moment, just so I could focus on other stuff). All transactions must be signed by the sender, allowing recipients to verify the sender identities.
2. You can place "transaction validators" at any node in your state trees, and any transaction affecting the subtree under the validator will be checked by that validator. Currently, there's a "permissions" validator included that gives a simple way to control writes based on the Ethereum keypair I mentioned above. The current implementation of the permissions validator isn't very well fleshed out yet -- it just lets you specify a true/false write permission associated with a [user, keypath regex] pair -- but it's a decent placeholder for now, until I can get around to roles and policies.
3. You can also write custom transaction validators in Go/Lua/Javascript, which should make it trivial to implement just about any access control model you desire.
4. You can also create a "private" tree by explicitly specifying the set of users who are allowed to read from and write to that tree. The default Redwood node implementation does automatic peer discovery and keeps a list of peers whose identities/addresses have been verified. When it receives a transaction for a private tree, it only gossips that transaction to the tree's members (as opposed to its behavior with public trees, which is to gossip transactions to any peer who subscribes to that tree).
5. We also want secure persistent storage for transactions so that we can get high availability and redundancy without compromising the security model. To facilitate this, we allow you to configure the node to talk to what we're calling a "remote blind store" (essentially a key-value DB running on a separate piece of hardware, possibly off-site). The Redwood node encrypts transactions with a key the remote store doesn't possess and sends it over gRPC to the blind store.
6. Some applications will have a high volume of transaction data, and will want to be able to prune/merge/rebase that data to save space. To prevent bad actors from issuing malicious prune requests, the remote blind stores are going to implement their own p2p protocol involving threshold signatures. Prune requests will only be honored if a quorum of these blind stores sign off on them.
We've been thinking about this quite a bit, but not publicly. I'd love for someone to help us punch holes in it!
Dying? Hm, not to my knowledge. In fact, I saw a highly-commented thread on HN just a couple of weeks ago about Cap'n Proto. What gives you the sense that it's on its way out?