d10

When I had this need I put together https://src.d10.dev/lotter. It takes as input ledger-cli entries and puts out entries with lot info added, which you can then run through `ledger`. You can quickly scan its output and see if what it does makes sense to you.

The repo hasn't seen activity for a while, but AFAIK it still works. I just haven't needed it myself recently.

I've also experimented with Go for both frontend and backend, using WASM. The approach I took was build the client-side like a backend service. What I mean is, some (normal) requests from the browser reach the hosted server, while others reach the local WASM. That code running locally is written like a server, i.e. HTTP handlers.

It's definitely experimental. In my experience it pairs well with HTMX or Unpoly for a good UI. You can see a live demo at https://clientcide.d10.dev/.

  Location: Reno/Tahoe, NV USA
  Remote: Yes
  Willing to relocate: Yes
  Technologies: Golang, Linux & BSD, SQL, cryptography, cyber-security, GCP and various cloud hosting, others omitted for brevity
  Résumé/CV: available via email
  Email: HN+hired at d10 . dev

pkg.go.dev supports fossil-scm (and I believe any "go gettable" source repo). So, the idea that it "hard-codes a list of centralized git ..." needs a citation.

Whereas AFAIK godoc.org only supported git. IMHO support for a variety of SCMs makes pkg.go.dev a huge improvement.

Support for "go get" and pkg.go.dev via fossil-scm does require some golang-specific meta tags, as TFA exclaims. But why is that a big deal, it's a golang repository after all?

  Location: Reno/Tahoe, NV USA
  Remote: Yes
  Willing to relocate: Yes
  Technologies: Golang, Linux & BSD, GCP, cryptography, cyber-security, others omitted for brevity
  Résumé/CV: available via email
  Email: FantasisticJobOpportunity at d10 . dev

Interesting! For folks who like this idea, I recommend looking up Ryan Fugger's Ripplepay (https://classic.ripplepay.com/). That was inspiration for Ripple Labs, who unlike Offset did go the cryptocurrency route (XRP).

I appreciate that Offset is not spawning a cryptocurrency where it doesn't need one. There are other projects influenced by Ripple and Ripplepay which are also not their own currency. For example Synchronized Network Accounting Protocol (https://michielbdejong.com/blog/20.html) and Interledger Protocol (https://interledger.org/).

One of the thought provoking ideas in interledger is that a single payment can be delivered in packets. Meaning that if Alice is making a payment to Bob, some of that payment might go through an intermediary Ivan and some of that same payment might go through Isaac. I haven't read much about Offset, but I saw that it described payments as atomic. Interledger specifically decides not to be atomic. This is not what most people expect with payments, but giving up atomicity gets other nice qualities. For example, if Alice is making a large payment to Bob, they are not limited by the liquidity of any one intermediary. Like data finding an efficient route on the internet, a payment can find an efficient route over interledger.

Glad to know about Offset. I'll add it to my list of interesting network money projects.

The authors of this paper didn't have "blockchain" in mind. Imagine rockets, or airplanes, with redundant systems on board. If, say, 3 of 4 sensors report "lower the landing gear" while 1 of 4 reports "don't lower the landing gear", then a hard requirement of the Byzantine Generals Problem is that "lower the landing gear" wins, assuming a majority of sensors function correctly (loyal generals).

Nakamoto consensus addresses "double-spend". Say I have exactly one coin, and I broadcast a transaction that sends the coin to Alice. All miners on the network consider my transaction a candidate for the next block, and get busy hashing proof-of-work.

Moments later, I compose a transaction that sends my one coin to Bob. And, I start mining a block with only that transaction in it. Now, its a race. If I win the race, the coin goes to Bob. If anyone else wins, the coin goes to Alice. Importantly, the coin will not go to both Alice and Bob.

In Nakamoto consensus, exactly one miner wins each race. And that miner, "loyal" or not, determines whether the coin goes to Alice or to Bob. To satisfy Byzantine Generals, in this particular example, the coin should always go to Alice. But in Nakamoto consensus it might end up going to either Alice or Bob.

Solving double-spend in a network of untrusted nodes is a significant feat. (And, according to the market, extremely valuable.) However, as I think your question is designed to point out, Nakamoto consensus does not solve the Byzantine Generals Problem. No offense to Nakamoto, it solves a different problem.

It's worth mentioning the concept of "byzantine faults" - meaning a node on the network might not be simply buggy, it might be designed by a malicious adversary to do any behavior that could exploit vulnerability in other nodes. So, if you're reading the next revolutionary ICO whitepaper and see, "we use Nakamoto Consensus to solve double-spend, even in the presence of byzantine adversaries", maybe keep reading. But if you read, "we use proof-of-work to solve the Byzantine Generals Problem", maybe save your money for another investment.

Thanks for taking time to reply to comments here.

If I understand correctly, when facebook detects faces, it does something like...

    compare face to all Face Templates
    if match
        associate picture and face with matched user
        (maybe also update Face Template of matched user)
    else
        discard data structures created during compare
        (maybe mark face as "already compared")

I'll speculate that facebook will never "delete its internal record of your face" as the title states. They're using misleading words to make this sound like a significant concession, when it isn't.

Suppose Alice appears in photos with Bob. And that Carol appears in other photos with the same Bob. Facebook can infer the Alice..Bob..Carol relationships.

If Bob "opts-out", facebook will still know that Alice appears in photos with unnamed person, and also that Carol appears with same unnamed person. So they'll infer the Alice..unnamed person..Carol relationships.

If, hypothetically, facebook offered Bob the option "do not use my face in your algorithms." Then maybe they wouldn't link Alice and Carol. But all facebook is offering here is "don't associate my face to my account".

This cleverly gives facebook some cover. Bob might ask facebook, "don't use my face to surveil my friends", but facebook can say "how could we possibly do that? We don't associate your face with your account, so we can't associate your face with your preference, even if we wanted to."

I think of Firefox containers (and Chrome "people") as providing a little isolation, but not enough. If I browse HN in a container, I'm likely to follow links to a lot of different domains. I'd have to diligently select the right container each time.

I'm suggesting instead the browser never mixes a cookie I was assigned while browsing say nytimes.com with a cookie assigned while browsing washingtonpost.com. Even if I regularly browse these domains in my "news" container.

A similar idea has occurred to me. I imagine a browser plugin that allows third-party cookies, but associates them per-domain visited. That is, the cookie that google analytics gets would be different when I'm visiting siteA.com vs siteB.com.

I don't share the author's optimism that dialogue will result in "a new identity end state that works for everyone." I believe on-line privacy has to be protected through non-negotiable mechanisms, against the interests that stand to profit from taking it away.