brynb

with that said it’s quite easy to write an equivalent- https://github.com/redwood/redwood/blob/develop/utils/mailbo...

that seems like a bigger lift than just deciding to help fix the bug

“be the change” or some such

(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"

and then there's go, wherein you simply don't import anything outside of the stdlib. a stoic and rather perfect immunity to this nonsense

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).

Turns out it makes for a great self-hosted git solution, so I made a git remote plugin that allows you to interact with it using regular vanilla git commands: https://github.com/redwood/redwood/tree/libp2p-connectivity2...

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

Thought I'd share a project I've been working on over the past year that meets at least a subset of the criteria from the article:

https://github.com/brynbellomy/redwood

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.

Just wanted to thank you for your brilliant work!

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?

Creator of Redwood here, which is similar in many ways to this and GunDB (hi Mark!). Agreed that we need more projects like this.

Redwood might be better described as a "p2p application platform" than a realtime database, but there's plenty of overlap. It's written in Go, supports HTTPS, Libp2p, and WebRTC transports (and soon, a Cap'n Proto RPC interface). It can also:

- serve as a Git remote

- stand in as an application server (you can upload assets directly to it, and they're served over regular HTTPS)

- execute Lambda-like functions written in Go, Lua, and Javascript that can be installed at any point in a given state tree

Would love some early feedback, and also to discuss similarities and differences with Sapphire's model. I've set up some demos in the "scenarios" folder -- a chat app, a realtime document editor, and a Git integration. Take a look if you're interested:

https://github.com/brynbellomy/redwood

I've been working for a few months on a database called Redwood that's intended to make it easier to build this kind of software. Having spent much of the past couple of years working with libp2p, IPFS, Dat, and similar technologies, I was curious to see what would result if I started from the ground up.

https://github.com/brynbellomy/redwood

So far, the model seems promising. It's fully peer-to-peer, and supports decentralized identity, configurable conflict resolution, read/write access, asset storage, and currently is running across 3 different transports:

- HTTP (augmented with extensions proposed by the Braid project [1][2])

- Libp2p

- WebRTC

I've included two simple demos, a collaborative document editor (well, it's just a textarea at the moment), and a chat app. Would appreciate any feedback or participation that folks are willing to give.

[1] https://github.com/braid-work/braid-spec

[2] https://groups.google.com/forum/#!forum/braid-http

You should check out the Braid project. We're already working on IETF drafts for a protocol of this nature within the HTTP working group.

- https://github.com/braid-work/braid-spec

- https://groups.google.com/forum/#!forum/braid-http

We’re building something along these lines at Axon (http://axon.science). Sign up for our beta if you’re interested in checking it out, and we should be able to get you set up in the next few days (we’re just starting to roll things out to the public this week).

The basic idea is distributed version control, like git, but over p2p swarms rather than clusters around “central” repositories. We have special handling for large datasets (but still using git) to improve transfer efficiency and diffing.

There’s a UI layer for collaboration (discussion, PRs, review) that supports deep linking to and embedding of files at specific commits, which sounds a bit like what you’re looking for.

Feedback is very much appreciated!

Long time lurker, just wanted to share some tutorials I've started writing. Let me know how it reads (and if you can get the example project working)!

(John Steinbeck, East of Eden, right?)

I've just started writing a book on GitHub that intends to offer a bunch of systematic, practical approaches to anxiety, depression, and other mental disorders, as well as a sort of "general take" on how to skillfully live as a human being (under a variety of circumstances). I've literally just started throwing the notes together, but if you're curious to see it evolve from step 1, it's here: https://github.com/brynbellomy/datwantendo

EDIT: so far, it draws from Aikido, Dialectical Behavior Therapy, the psychology of video games and virtual experiences — new additions will continue to be as diverse in origin (hopefully).