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
Experienced software developer, strong in both tech and people
skills. Looking for senior role or early stage. See d10.dev/about for
links to open-source work, and examples of the kinds of problems I
like to solve. I'm happy to share a resume, if you send an email briefly describing an opportunity.
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
Software guy with a lot of experience, looking for senior role or early stage. See d10.dev/about for links to open-source work, and a sense of the kinds of problems I like to solve. I'm happy to share a resume (if via email you seem more human than bot).
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.
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."
That’s not accurate. If you are not a user or don’t have the FaceRec setting on, we will not create a Face Template and won’t be able to recognize you in pictures.
Source/Disclaimer: I work at FB and this feature is managed by my team.
While I desperately want to trust you on a human to human interaction, and I genuinely do want to trust you, we’ve been misled with disingenuous language by companies at FB’s scale so many times for years, I’m finding it difficult to trust FB at all—it isn’t you, at all, it’s Facebook’s and similar companies intentional fogging of language which leads do this distrust.
And while I do want to trust you, I can’t trust that the company/industry itself wouldn’t figure out a way to exploit it at a later date :(
It really does make me sad that I can’t trust what you’re saying, i think a fundamental part of humanity is wanting that level of trust, and it’s been intentionally exploited.
I totally agree with you. I will never trust what Facebook says. And not only that. When I look at pesenti's clarifications, the only think I can think of is: "They will probably start safe and really not create any face templates for now (during people's attention is on this topic), but after a few weeks/months (when the topic is no longer discussed) they will start doing it anyway. That is the amount of trust I have for Facebook (and Facebook is not alone in that category). Nothing good can ever come from Facebook.
> I work at FB and this feature is managed by my team.
How do you feel working at Facebook? Do you feel pressure from your peers on the outside about the moral compass of the company?
Maybe you can't answer these things if you aren't using a throwaway account, but I'm very interested in hearing how Facebook employees perceive the company themselves, as well as how they're treated by company outsiders.
My impression is that a lot of engineers are opposed to how Facebook operates and that this reputation must make recruiting and retention difficult.
> My impression is that a lot of engineers are opposed to how Facebook operates and that this reputation must make recruiting and retention difficult.
In machine learning and computer vision they are a very desired company to work at, at least on the research side of things (FAIR). They have very good people and world famous ones, lots of powerful hardware to work with etc. I'm sure they have no problem with recruiting brilliant people from all over the world.
This doesn't sound like the use case that the parent comment was describing. Parent comment was about what is inferred if you are a user and no longer have FaceRec setting on, but used to have it on at one point, and opted out. That's why the speculation was that "facebook will never "delete its internal record of your face" as the title states."
Edit: not to be snarky, because I'm pretty sure that wasn't your intention, but it sounded like you were doing exactly this:
> 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."
Everyone understands how opting out works and what it means (I mean, some of your bosses pretend they don't, but even they do). Of course you can't create a template when the setting that disables template creation is on. The question is what do you do with data that you inferred in the past, and what kind of privacy can be expected if you opt out of a feature after it's been used. That's particularly important given this industry's history of opting in for you.
The problem is that language is ambiguous and it’s important to be accurate. I do believe that intent wise, it answers the question the way you would prefer. Let me explain.
In the case you describe, Facebook no longer creates a Face Template, that is some kind of ML model of your face that could be used to recognize it or identify that you are the same person appearing across new pictures.
But I can’t say Facebook no longer has a record of your face. It still has some pictures, uploaded by your friends, where you appear. It won’t know that it's you OR and if your friends upload two pictures where you appear, it won't know that the same person is in both unless they tag you manually (which they can only do if you are user and authorize them - but that's a different setting).
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")
If the data is truly discarded, great! I'm glad if my earlier speculation is not what happens.
Exactly. You still need to detect which person is in the photograph in order to determine that it is a person who has opted-out. This feature is an incredibly half-assed PR attempt.
There are gaps in your use of language here which is exactly what the parent is talking about. Facebook could turn around later and say "we never said anything about a Face Stencil".
But on each picture you automatically recognize when there is some face. And you need to be able to learn new faces. So doesn't it make necessary for somewhere in the system to be your face model in order for system to decide to ignore it? Not my field so I'm clueless but I would assume that without such hidden model it would be more likely to match the next most similar person? (I'm guessing social network is also taken into account to make such mistakes less likely?)
What happens to unknown faces in photographs, you just discard them? What if I have 1000s of photo of aunt Emma, but aunt Emma is not on Facebook. When she eventually joins, and turns Face recognition on, will you rescan all my old photos to identify her? Or will Face recognition only work for new photos?
Don't you have to try to identify a face first, before you can decide you don't want to identify it? I don't see how it can work if you don't try to identify every face.
You identify that there is a face yes, that's face detection, https://en.wikipedia.org/wiki/Face_detection, which is not the same as face recognition and doesn't need a model per person.
"When you opt out of facial recognition on Facebook, the company will delete your template, meaning it will have no original reference point for your face and therefore cannot find your face at all."
...
When people turn off their face recognition setting, we can no longer create a face template for them for any purpose, including A.I. research,” the spokesperson told OneZero.
I think d10 is saying that, by deleting your face template, they will still have "unnamed person 7749" in 45 different photos, which happen to be YOU, which they won't every say again, but you're still in there, linked up to all those people... possibly creating new relationships between people that don't have the same friends but went to the same wedding, all because you're in both sets of photos.
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.
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.
The repo hasn't seen activity for a while, but AFAIK it still works. I just haven't needed it myself recently.