> Without sample-and-hold circuitry, this meant the stereo channels were approximately 11 μs out of sync.
Am I correct in assuming this wouldn't be perceivable on a stereo, based on the speed of sound?
3,974 karma · joined July 18, 2011
Am I correct in assuming this wouldn't be perceivable on a stereo, based on the speed of sound?
A close family member was diagnosed 5 years ago and went through a stem cell transplant at Dana farber and the cancer still hasn’t returned…although statistically by now I believe it should have. But when it does return there is now a massive menu of next treatments for her that will likely hold it at bay.
Things are changing so fast now that I’m not sure the stem cell treatment is the first step.
Good luck to your dad.
- when a user changes the score slider, encode that in the URL with a hash tag, so they can bookmark the page with their preferred settings
- a left button allowing me to step back to yesterday's news
- to simplify newsletter signups, just accept an e-mail address right on that page
- your **advanced** options:
- have GPT score each news story across common labels: science, politics, entertainment, news, etc. Then allow these as a filter. If I want to see the top science stories of the day, that should be easy.
- have GPT write a 2 sentence summary of each story as a lead-in after the headline title
- a user/saved whitelist/blacklist of news sites
- any advanced setting should be shareable. For example, if someone puts the effort in to make a page with just Australian news sources, focused on sports, with a minimum score of 5.0, they could save that with a title that can be shared for anyone.
One of the most well-known examples of a foundational model is the GPT (Generative Pre-trained Transformer) series developed by OpenAI. GPT models, like GPT-3 or GPT-4, are trained on large datasets containing diverse text from the internet, which enables them to generate human-like text, answer questions, translate languages, and perform various other tasks.
Foundational models are significant in the AI field because they allow researchers and developers to create a wide range of applications and solutions without having to train a new model from scratch for each specific task. This approach saves time, resources, and computational power while still providing a high level of performance across different tasks.
P.S. I'm the blog post author. BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zk7RUjCs bLeGBWHRNe047t1 63n5tVSjvbZwtwt nQVqdDHEZIR4kgD PpRDesKecb1Y4U2 jcnOUuLfKvsiGZY PP7SbO79zoRFEuv e8gXRm44Brjfdym iwy2mGXI9VW5PDf WMxwJdTflgruGMK SUkEhjqwUOEc8KR AC6aF8iJadgq3bz oGMLpY750H1Deus EGPgtQQVIeh05mx HY7K3oFOn3SjeS3 cL1duil9YgmZi1y zKu3bfFSbjelgzc 5UMZ42xTJJs0gT. END KEYBASE SALTPACK SIGNED MESSAGE.
This article isn't just misleading; it's entirely false, and the title is both highly damaging AND false. Someone below threw out the word "libel" here. I don't know about that, but it's incredibly frustrating to read this title on HN right now.
* THERE IS NO BACKDOOR HERE. Neither the especially scary kind suggested by the title (everyone assumes encryption breaking!), nor the coerced attestation kind suggested in the text.
* Put simply, KEYBASE HAS NOT BACKDOORED its apps and cannot coerce them into signing someone else's Stellar address into a profile.
Further, THIS USER VOLUNTARILY GENERATED A STELLAR PRIVATE KEY. What follows is the flow for generating a Stellar wallet and attaching it to one's profile. The author of this post went through this flow on Feb 4, 2019:
1. Visited the "wallet" tab in the app
2. read a brief description of Stellar in a modal.
3. Saw our disclaimer in a modal (not hidden - printed out front) about how scary cryptocurrency is, how it's permanently attached to your identity, and how it's important to backup your private key if you plan on leaving Keybase.
4. Only once they accepted that, then their client app (not our server) generated a Stellar private key. The app signed the public Stellar address into his sig chain. And the Stellar private key counter-signed, proving bidirectionally. The stellar key was then encrypted in a way so their devices could gossip them to each other.
So to be clear (1) this writer did in fact have that Stellar Key. And (2) we, Keybase, did not. And (3) they knew they were doing it. I encourage anyone curious to go try it out -- the flow has not changed.
I don't understand what their agenda is here. Offering some charity, perhaps they went through this flow late at night and forgot. (Looks like they generated their Stellar account well after midnight in Europe.) But the claims in the post are just false.
I accept some people don't like the opinionated cryptocurrency partnership Keybase has formed. We do like Stellar. However, that doesn't change our security story. Nor does it force users to set up Stellar keys, and something like half of our users have not. Actually - we spent a great effort building around the fact that many users wouldn't be interested in the cryptocurrency side of things.
For those who generate Stellar keys and then change their mind, not wanting them, we'll add the feature to delete all of them.
Anyway, this is just not true. All of it.
One of the biggest devops pain points for a large team and large infrastructure is updating N servers every single time a team member is added or removed. Of course there are some other solutions to this problem, but the Keybase one is extra slick and just works automatically once it's set up.
It's also entirely powered by an open-source 3rd party bot, so it can be forked for improvement or to build something else triggered by cryptographic team membership changes.
If you haven't been through this kind of thing, it's hard to understand how scary it is to have a break-in of unknown origin. If you use strong, unique passwords as Max did, then you're almost certain it's a server break in (and again, this is why Slack is scary for sensitive info)...but being 99% certain isn't enough. Removing that computer permanently from the team gave peace of mind.
Ah spell-check in the desktop app. We explored one library and weren't happy. We're visiting option soon, but yeah, privacy is critical.
For now, we want to talk to everyone working on integrations, so we can see what steps are working and what are confusing, what could be improved, etc. So we're talking to everyone doing an integration.
Keybase's view: identity on the Internet should not be just about Twitter, Facebook, and the other superpowers. Your membership to any site might be meaningful to other people, whether that membership is to something small like a phpBB forum about motorcycles, or something big like LinkedIn or Etsy. Often, the smaller the community, the more meaningful and close-knit membership is. And the more that community might want access to secure tools such as Keybase. If you're on the forum, you might _really_ need to reach out to another user of that forum, securely.
It might be a good time to mention that Keybase is looking to hire an Identity Evangelist[1]. This would be someone with a tech background (i.e., from the HN crowd), who has great presentation skills and experience, and who wants to help other sites and apps integrate with Keybase.
Also: during our fundraising, we faced a number of the "Monday pitch meetings" -- this is where you've gone through the early crap talking with VC's and are invited in to pitch to the partners. It's typically the last step before an offer. a16z's partner meeting was, by far, the most tech-savvy and aware group. It seems obvious that VC's would understand the technology they're investing in, but honestly, that's often not the case. We faced a lot of brand-name VC firms that couldn't understand what we were working on. We'd get a sense of that and quickly adjust our pitch to focus on what they could understand.
For those asking "Why give them so much credit when they're just doing their job?" -- there are special occasions when a startup's interests and its investors' interests are not aligned. The first big opportunity for a VC to mess with you is the period between a letter of intent and closing the round, when all the smaller details come up and are negotiated. a16z was excellent in the process and we closed quickly without issue.
A later possibility of disagreement is what ar7hur describes here, and here's why it happens: VC's have zero risk aversion and aim to maximize expected value in dollars, which is what you'd want as an investor in the VC. But especially if you're a first-time founder, your dollar-to-utility curve is anything bit linear. Most humans wouldn't trade $5 million for a 1-in-10 chance at $100 million. This discrepancy is the source of a lot of possible problems. How VC's behave during both subsequent rounds and possible exits is perhaps the most important measure of them from a founder's perspective.
tl;dr very happy with a16z and Chris Dixon.
We'd rather focus on the positive solution to the problem (which Keybase has implemented), rather than just pointing a giant finger at any other services which have the problem we're trying to address. I think I personally will sleep better tonight this way.
Still we want this conversation to continue.
This comment may be of interest (we could release server code at some point, and I will take this as a vote), but I hope people reading this aren't distracted by Signal's flaw here.
[edit: chilled a bit!]
The goal is a 1-1 mapping between devices (keys) and these names. So whenever we need our UX to talk about a key, it can talk, safely, about it in terms of device names. Once committed to your chain of signatures, "Laptop-Warhol" means a specific device key, and it can't be used again. So, for example, if one of your Keybase installs wants to tell you "oh, Laptop-Warhol just added a new device, iPhone-Vangogh" then it doesn't need to look like this: "Key 34858234589234895897234598734 added key 90123845890230948234234324."
If Laptop-Warhold could mean multiple devices (keys), well then we'd need to start talking about the keys. Which is a nightmare for usability.
A lot of this decision was driven by something we've seen with apple devices. Every now and then I'd get a popup on my computer - say when updating iOS - that said something like "you just started using iMessage on a new device, 'chris's iphone'. if you don't know what this you should freak your shit out." well - it has basically said that so many times with the same names over again, that I can safely assume that it's a near-useless warning.
Note I mean unique to you; 2 different users on keybase can name their devices the same.
Generally speaking...it's been a goal from the beginning that names on keybase are meaningful. Similarly if you look up "chris" in in our merkle tree (which is pinned to bitcoin) that leads to a deterministic chain of signatures. inside that chain, where I mention "work-imac-warhol", you're guaranteed to see the same answer as I am. So "chris" is as good as a key fingerprint or safety number. And so is my device name.
The background: we talk about it sometimes as a solution to a real problem: in certain teams and workplaces, people can be afraid to give honest feedback (who dares to submit an "anonymous" survey to HR?), but Keybase may be in a unique position to let people in a group give written feedback, vote on something important, or rate an experience. Without any risk of exposing identity, short of writing something identifiable in a text field.
I'd be curious, personally, to see management get a yearly vote of [no] confidence, for example. Is that crazy?
Keep in mind we are mostly focused right now on user experience and performance improvements. But we allocate a certain amount of time to cryptographic features that just aren't possible in other software, such as this coin flip thing. We've been talking about voting and surveys, too.
Each little square inside it represents a byte, so we map bytes (0..255) to colors ranging from a blue to a purple.
The matching secret is also 32 bytes, and of course those come in in random order, so we line up secret rows with the matching commitments. It sure is fun to watch.
We played with some different visualizetions. We actually had one version with a 3d sphere getting covered in data, but it felt too gimmicky. This gives a good feeling of people showing up.
If you're one of 10 people doing this to the light switch, then as long as you choose randomly, it doesn't matter what the other 9 people do. It has a 50% chance of ending up on and a 50% chance of ending up off. Even if the other 9 people are cheating together.
Of course this has the problem that whoever goes last wins, which is why the commitment ceremony is necessary.
I didn't cover some details I find fascinating but which might have been overkill outside of HackerNews. For example, some assume the "one-way"ness of a hash function makes this protocol work. But that's not enough: we can't have Alice generating 2 different secrets with the same hash, even if Barb can't reverse the hash. What we also need is _collision resistance_, so Alice doesn't get to pick and choose what to expose in the final stage.
https://en.wikipedia.org/wiki/Collision_resistance
Lately, we've made much bigger, but less blogworthy, improvements to Keybase. It's faster, team on-boarding is getting better, and we'll be launching a very improved UX in the next month or so. I rarely get to stop and write about Keybase, so this was fun.
And for anyone looking to test, I'm `chris` on keybase. You can start a chat with me and do a `/flip cards 5 chris,yourname` and we'll see who gets a better poker hand. If you can deal yourself a flush or better on your first try I'll give a prize or something? Who knows. Anyway, we're having fun with it.
There's the suggestion that an exploding feature is worthless, given your partner can just take a screenshot or video of what you sent.
This suggestion is missing (1) that your relationship with a partner is disproportionately okay at the time you sent something (i.e., you trust them THEN) and (2) there's a whole different class of adversary who compromises your or your partners' devices in the future.
SnapChat, as far as I know, has none of the cryptographic implementation of Keybase. And yet it has likely protected hundreds of thousands of kids from severe bullying. Consider the teen girl who sends the goofy sexy pic to her boyfriend. Before the advent of exploding messages, he might've iMessaged or emailed that to a friend, just one friend, his best friend, out of pride. And that friend sent it to a few more, and so on. Not out of malice, but suddenly the whole school has seen her pic of god knows what and she literally wants to die. But with Snapchat, taking a screenshot is knowingly violating a social agreement. It's also violating the trust of his current girlfriend - everyone knows it's not okay to screenshot that shit. And the number of people who would do that is much tinier. Second, consider the far worse scenario: she dumps him a month later and until then he has been NiceGuy. But then he becomes r/niceguy, the guy who will look through the old pictures and spread them around.
Finally, let's not forget that your device can be compromised by loss, theft, or hackers, at any time. Exploding messages are gone when that happens.
People can be tricked, compelled, coerced, blackmailed, and hacked. Or just turn evil. All in the future. Which is what a timed message protects against. This is why Keybase is doing this. Paired with encryption it's quite powerful.