alanfriedman

For anyone looking to download the data, here are a few links:

Empire Blue (Anthem): https://www.empireblue.com/machine-readable-file/search/

United Healthcare: https://transparency-in-coverage.uhc.com/

Aetna (Seems like the right page, but I don't see any download links — possibly because they haven't been posted yet): https://health1.aetna.com/app/public/#/one/insurerCode=AETNA...

Search keywords: https://www.google.com/search?q=machine+readable+files+trans...

Out of curiosity, what were some of the differences in work culture you experienced? I've never worked outside the U.S., so would be interested to hear a different perspective.

You can try to prettify/beautify (something like http://jsbeautifier.org/), but the output can still be hard to read. If you're looking to learn how to build a particular feature that's closed-source, I'd recommend trying to build something similar yourself using tutorials or an open-source analog.

You'd have better luck analyzing the source rather than the minified output. Relevant code is here: https://github.com/seripap/darkwire-client/blob/master/src/u...

My point was that if the server providing client code is compromised, it can serve malicious code to said client. This isn’t a cryptographic claim, just a point about how all web-based applications work.

Also while I appreciate the feedback, this comment struck me as more hostile than helpful, so I’d suggest having a look at HN comment guidelines for future reference.

Thanks for the feedback. If we assume the server is compromised then it's true that a MITM attack is trivial. However it seems to me this would be the case for any web-based e2e chat application, all of which must use a server by definition.

Regardless, it's easy enough to spin up your own instance of Darkwire (`docker compose`) and operate the server yourself if so inclined.

Thanks for pointing this out. We'll work on getting fixes in ASAP.

Firstly, thanks for inspecting the source and offering a suggestion for improvement. The latter point should be a relatively easy fix.

As for your first point, there’s little we can do to prevent TLS or AWS tampering. But we can make it easier to choose e2e encryption in the first place. So we focused on reducing barriers to entry (no signup required, simple URL-based rooms) as well as providing these benefits over alternatives:

- Open source code

- Ephermeral message history (not persisted in a DB)

- Opt-out anonymity

We think these features make Darkwire a good solution for many users seeking secure, private online communication. Having said that, no solution is perfect and we hope to see contributions from the open source community to make it even better.

Thanks! We actually need the server intermediary to handle storing and locking rooms, and adding and removing members. Also IIRC WebRTC data channel doesn't have great cross browser support.

Darkwire is more for ephemeral chat rooms, where the name doesn't change as long as the room is occupied. We also don't require sign up, so you can use it instantly and anonymously.

The testimonials section is hilarious and the app looks great too.

This is neat. What radius is used for viewing messages in a given area?

Yes I think so too. Long-term I'd like to have a extensions (Chrome, desktop, etc) that give access to running blocks from anywhere. I think this makes code much more usable to non-developers.

I thought about it, but the goal is for codeblox to be language agnostic, so it would need to run server side. Eventually I plan to add Python and Java support. It would reduce costs though, that's for sure.

Thanks! I agree about conditional logic - maybe also loops - and will be thinking about how to incorporate something like that.

Thanks! The plan is to let the author specify the license type in the codeblox.json file, similar to what you would do on GitHub or with an NPM package.

Hi HN,

I built Codeblox to allow developers to connect code together like building blocks. This makes it easy to build sequences (series of blocks) to do all kinds of things.

Every block and sequence gets an API endpoint (POST api.codeblox.io/username/blockName) and you can also schedule them to run daily.

Each code block specifies an input and output type (text, number, location, etc) and you can build sequences by combining blocks that fit together.

How it Works:

- CLI tool packages up your directory as a ZIP file, and uploads it to S3 - That filename is stored in the DB - When someone invokes your code from the website, the back-end (Node.js) creates a Lambda function pointed to your ZIP in S3, invokes it and returns the result - For sequences, do the same thing, except the client handles making each sequential call

Stack: FE: React/Redux BE: Node.js, MySQL, AWS, Redis

I'd be really interested to hear any feedback or feature requests.

I'm also looking for a co-founder to work on this with (NYC or SF area), so if you like the idea just reach out at info [at] codeblox [dot] io

Thanks! Alan

Haha thank you!

This is incredible. Thank you.

Yeah that would be a good idea.

We will provide a detailed migration path from legacy boolean systems.

We will resist all intrusions of our users' privacy and/or booleans.

Reach out to hello@booleans.io.

Mongo didn't meet our strict security and performance requirements.

Of course not...

Thanks for the good times everyone. If anyone's interested in making this a real thing (IoT, state manager, web hooks, auth, labels, analytics, GUI, etc) reach out at hello@booleans.io. I'd love to build it out but have a day job so it's tricky. The BaaS future is one of endless opportunity.

You guys have been nice enough to not bring it down, so all is good so far. Peak load was 600 concurrent. Not sure on DB queries.

Also the stack is Node/Express and MySQL.

We spent years waiting for our BaaS patents to clear (the patent office was confused) and now we're ready to take on the world.

We have our best and brightest working around the clock to deliver <50ms latency at peak load.