malgorithms

I wrote the “ai” for one of the early popular forks of Slime Volleyball. I have a lot of fond memories! Recently I wrote a modern interpretation of the game in pure TypeScript/html canvas. It requires a real keyboard or gamepad - sorry no phones. Some of the single player ooponents are pretty fun. It’s at https://tippycoco.com and it’s all open source.

You’re probably in the process of learning this now, but in case you’re just getting started: effective multiple myeloma treatments are being approved at an astonishing rate. It was a death sentence 20 years ago. Now it’s indefinitely treatable for many people.

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.

I'd been waiting/hoping for someone to make something like this. Well done. A few ideas that will not clutter the UI but you might consider:

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

According to GPT-4, and I think this is a good summary: A "Foundational Model" in AI programming refers to large-scale machine learning models that serve as a basis for a wide range of applications and tasks. These models are pre-trained on massive amounts of data and can be fine-tuned or adapted for specific tasks, domains, or applications.

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.

Slime Volleyball directly inspired it! I mention that on the about page, https://tippycoco.com/about . And ~20 years ago, I actually programmed one of the popular Slime Volleyball bots.

I say this because investors sit on boards and work alongside these lawyers once they invest. They learn pretty quickly who is great and can often give very direct recommendations: a specific lawyer, not just a firm. At the startup stage you should choose the lawyer, not the firm.

If you’re talking to investors at all, ask them for recommendations. That’s a good place to start.

As an example of the magic referred to in the post, here's some encrypted text that could be read by `pg` here on HackerNews: https://pastebin.com/raw/bxRaymaB . As explained in the article, the unlocking step trusts HackerNews at one step in the process.

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.

Official response here - I work for Keybase.

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.

Nope, that's not the case, in fact you'll get the Lumens automatically within a day or so. If you want to _continue_ after the first month, you'll need to click the button in the app saying you want to. But you have a month to do that.

Not a dark pattern, an accidental leftover string from our testing. Any account registered before today qualifies. I'll deploy a fix to that shortly. Update: deployed, although you may need to restart your app to update the text.

This was a summer internship project at Keybase, and the whole team is thrilled with how it turned out. The OP of this post is the author of the project and would be happy to answer questions here in HN.

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.

Further: Keybase is a security product and it wasn't deemed worth the risk for the CEO. And while Keybase isn't made of money, the $5k was roughly irrelevant compared to the other costs mentioned here and the _magnitude of the risk_.

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.

There is giphy integration, and how it works is described here. https://keybase.io/docs/chat/linkpreviews . Similarly we'll be launching a location-sharing (including realtime) feature soon, working on a similar model.

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.

David Mazières (designer of the protocol) has given a number of talks. Here's a good video of his talk at Google, and I believe it's the one I watched a couple years ago: https://www.youtube.com/watch?v=vmwnhZmEZjc

CoinMarketCap's paid API. We're open to considering other data sources.

Good q - this step will likely be automated soon. Still, there will always be one final step of our approving any integration, otherwise there would be 10,000 pr0n sites or ad sites. (We mention this in the FAQ.) But we can automate everything up to turning it on.

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.

Oh, wow, this jumped the gun for us. We weren't expecting to announce this until next week! It's also in a bit of a draft form, and we expect to improve this integration guide as we add partners.

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.

[1] https://keybase.io/jobs#evangelist

a16z - also Chris Dixon - led our round at Keybase. We only have great things to say about both the firm and Chris. Chris sits on our board and has been a class act the whole time.

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.

<3

I don't know the moderation policy on title changes at HN, but I just changed the title of the post. Internally at Keybase - and thanks to a conversation with a peer - we've been feeling pretty guilty about calling out a specific project that we think is basically the gold standard outside Keybase.

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.

Fair enough - I don't want to dilute my point by coming across as too hostile, even though my point is that it seems like a well-crafted diversion. Let me edit it down and your quote of the original can stand.

It _seems_ you (someone from the Signal project?) are actively diverting from the point, with what is ultimately a security theater request. Keybase's app - which IS open source - doesn't trust the server at all. We could be running anything server-side, regardless of what we do or don't publish. Meanwhile, Signal's story is "you MUST trust our server, over and over again," as the blog post explains. Unfortunately there's no way to know what's happening on the server. So being like Signal and publishing your server source is strictly worse than being like Keybase and not (yet?) publishing server-side source. At any time, Signal could be throwing in these fake key upgrades, either due to running other source code on purpose, or being forced to, or just plain getting hacked. The most malicious Keybase server could not.

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!]

Oh interesting. I don't think we've talked about this decision publicly, so I can write about it for a second. Not letting people re-use a device name is an inconvenience, I admit, but arguably it's not like other cryptography inconveniences, where people are confused, troubled, etc. We figured people would say "huh, weird requirement" and pick a different name and move on.

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.

I'd be curious if people on HN would want a zero knowledge survey and voting system inside Keybase, and if so, what would it look like?

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.

Yes! Each horizontal row in the rectangles represents a participating device. The purple/blue rectangle that comes in first represents all the bytes of the commitments coming in. Since we constrain the size of the rectangle it makes (IMO) a cool visual effect as the rows squeeze to accommodate more data.

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.

Perhaps an even simpler analogy is a light switch. Each person decides randomly either to flip the light switch or leave it where it is. This is basically what random XOR'ing is.

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.

Author here, thank you for the comment. "flip again" was added at the last minute, after a night at a bar...where some beta testers were making real-world decisions using the app.

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.

Author here. I'm seeing the same comment in 4 different places on here, worded with various amounts of hostility. I now wish I had addressed this in the FAQ on the post.

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.

Blog author from Keybase here. Always game for a Hacker News discussion!

There's a subtle point I cut from my post for simplicity reasons, but which feels perfect for HN. I've been convinced by Mazières and the Stellar team that the classic "blockchain" works great for native tokens but is extremely dangerous for anything with counterparty redemption. For example, imagine the shitshow after a truly contentious fork, if there are tokens which are supposed to be redeemable with a counterparty.

Let's say Deutsche Bank had put €1 billion into colored coins on Bitcoin. Suddenly, after a fork (e.g. bitcoin vs. bitcoin cash), there would be €2 billion IOU's in the wild. The people on each side of that fork would not roll over and die, and it's not simple to say "Oh, whoever Deutsche picks wins." Or even "Whoever has the strongest chain wins." I have a hard time imagining a company would ever take that risk. I worry big companies would never dare to put anything real-world redeemable directly onto, say, Bitcoin or Ethereum, for this reason. They'd just get sued over and over again.

The Stellar federated consensus story (HN debates about SCP below [1][2]) has Deutsche Bank as an actual player on the network. If you want DB redemptions then you would include them in your trust lines / quorum slices, and if Stellar fell apart and became partitioned, you would stay on DB's side. All said, it seems significantly faster and more stable for cryptocurrency-to-real-world mappings, both for the consumer and counterparty.

Fun discussions:

[1] https://news.ycombinator.com/item?id=9341687 -- of particular note, because it has David Mazières, Vitalik Buterin, and Greg Maxwell all weighing in.

[2] https://news.ycombinator.com/item?id=16125920