EmielMols

Hey folks, this is a small (couple weeks) project spun out of another chat product we're building.

The idea is that a lot of simpler "chat with us" use cases should not resort to intercom's complexity, and most other simple products really get it wrong by asking for name/email address first (rocket chat) or simply looking pretty ugly (olark). As a bonus, 99messages uses browser push notifications that work pretty decent in the non-iOS world.

Thanks for trying it out.

Let us know what you think, here or via chat at https://99ms.gs/99messages.

Edit: wording

Of course, but it would be cool if you could also calculate the public component on paper (and ideally verify it computerless as well). You could really create your bitcoin/ether/etc wallet with the public key only, whilst having an extremely low attack surface (private key never touches computer memory).

> Is it broke people, people working several jobs on minimum wage, ... people trapped in debt?

At least in Europe, it is not uncommon that bank/pension/state funds (in effect: everybody's money) buy in latest to these stocks.

Allocating resources in society is a hard problem, and capital markets overall provide a valuable service in deciding where resources should go. But when some of these markets function more or less like a lottery (or ponzi scheme), I don't see why a society should support (or even worse: idolize) its participants.

This a 100 times.

The crypto currency hype only (or at least mainly) redistributes wealth, in my eyes to (tech savvy) people-with-means-already.

Yes there might be empowering stories of "smart single moms" making serious money by betting on Bitcoin, but as a whole it only enlarges income equality between people, arguably one of the issues of our time.

This is not how markets work. Once the "self-driving capabilities are perfect and legal":

- investing in such a fleet would be like investing in any other kind of business: it's easier if you have the money, but if not you can go to any bank and get a loan.

- prices for a trip with a self-driving taxi will drop immensely, this is probably going to be a big liability if you would start the aforementioned business

- other effects that I can't think of right now

It is true that in a lot of places rich people have an edge on the less-wealthy (it's easier getting/staying rich if you are rich), but that's more of a generic problem than something that would be amplified by change to self-driving cars.

I imagine it would be easy enough to - at a discount - sell all the bitcoins to a (single) other party and have them sell the coins over time. Don't know if many entities would want to take such a position, but there are probably at least some.

If mtgox were still operational, they would probably take a loan (in yen) with the btc as collateral, if they needed the amount of money on a short notice (and provided they really owned the bitcoin by that exchange).

You could always "enhance" the business case by selling "whitelisting" to some of these data collection services. Just ask the guy from adblock plus.

> “What is the best lense for close ups?”

It's just point and shoot really.

I don't think so. Your API seems to be synchronous, where all modern IndexedDB/WebSQL/etc APIs use promises. The reason they do this is that in modern browsers storage often runs on a separate thread and/or use sqlite and you don't really want to stop-your-js-world when the rendez-vouz and sqlite processing can take 100s of milliseconds on mobile devices.

This really is one (of many!) of the ugly parts of modern JS development. Newly designed APIs will probably gravitate towards using Promises (because these also support sync backends - the other way around: not so much).

But, hell, it feels stupid having to allocate a closure to memory (and decorate your code with indentation and an additional function if you don't transpile using await) every time you just want to get your session token from storage.

This. If travel is avoidable or exchangeable for another destination, just don't go to the states.

As a EU citizen that visited Iran last year I'm no longer eligible for ESTA (visaless entry) and that - combined with these horrific border control policies - honestly made the threshold for me to visit so high, I'll probably never visit again.

I'm always stuped by the fact that when I search for SomeClass I get a dozen of results from tests and the actual class SomeClass in a file called SomeClass.x appears on page 4. Haven't found a way yet to exclude those pesky tests.

In The Netherlands almost all banks support a "forwarding service" when switching banks: direct debits to the old account will be forwarded for at least a year to the new bank (account).

You can bet the banks didn't think of this themselves, but it was probably forced on them by a consumer protection law. It is, coincidentally, something most Dutch people don't know exists.

As I understand, transactional email is often triggered by a user itself (new account creation, forgot password, etc). By definition, those are sent spread out over time.

This is - at least from a spam filter's perspective - a huge email broadcast, more akin to a news letter mailing or a spam run.

And semantics aside, a lot of those 43M users will consider the email to be unsolicited (didn't remember they signed up, don't care about computer security, etc). They will happily report such an email as spam, adding to the training set.

For one, it's pretty challenging to send out 43M similarly-looking emails within 24h without tripping a whole bunch of anti-spam filters - even when you're using tailored services (that distribute over IPs with good rep, etc) like Amazon SES.

We have primarily focused on our iOS/Android apps. That's where 99% of our funnel takes place.

Because everything was already built with HTML5 (or actually: WebKit's HTML5), we got Chrome/Safari support almost for free and that's why the web version exists.

Getting firefox and IE to behave is something that still needs some attention. Thanks for trying out!

Happening Plugins use Javascript (or Coffeescript compiled to Javascript) for backend logic with simple APIs for Push notifications/HTTP calls/Timers/group management (see for instance https://platform.happening.im/docs/server-app.html#app-data, or the server.coffee code on the platform page). This server-side javascript runs in custom V8 instances and calls out to the core Happening backend (which is implemented in PHP/Go/C++).

Thanks for pointing this out!

I don't think this is a huge problem. Yes, long running queries might introduce lag. When this lag hits a threshold of your choosing, PGBackup (or any service that would offer it) would then gladly send out pager alerts.

The same would happen if the WAL could not be retrieved in time (because wal storage full): PGBackup would start a new base_backup and send out pager alerts.

Thanks for your feedback! Are you comfortable with replicating your unencrypted data for your use case?

The base_backup+xlog backup is going to be our next feature. Backing those up to s3: possibly. Encrypted?

Great feedback here, but also through the on-site chat. Again, the current version is built with very limited resources mainly to check if/how the idea would resonate.

- We will try to add Point-in-time-recovery asap (saving base backups+xlogs). These would run of the replica, not putting load on your database server. As koolba correctly points out, this will make it more "backup" than "replica". Will have to figure out how this fits in the pricing model.

- I would personally love to offer better (guarantees of) encryption of the backups, ideally encrypt the data pages on the primary server. We would have to see how this would technically work.

- First couple of backups are currently replicating :)!!

Thanks, HN!

Technically, yes. But we figured the name "backup" is easier to remember, and this would allow us to add a bunch of other 'backup related' services later on :).

A pretty strictly configured lxc container.

Yes. Timely base-backups and PITR are obvious next features. We're really trying to determine if the idea resonates with people before throwing developer-years at it (or perhaps choosing a technically different solution to fix the problem altogether).

We might add proxy-over-ssh/vlan options later on, but it would be incompatible with the 2-clicks-and-your-done interface right now.

As far as I know, postgres authentication is rather simple and exposing the port does not easily add huge liability.

This is really a trade-off between ease-of-setup and better security. We're eager to talk to (a lot of) users to see what there current setup is and how PGBackup could add some value for them.

Thanks for this. That would be an ideal scenario for me as well (it's even mentioned in the FAQ).

It's technically rather challenging, but when enough users would ask for it, I know putting some resources into it might be viable.

Author here, To quote from the FAQ:

> Why did you build PGBackup?

> We were tired of constantly configuring a postgres replica for each (small) project. And then being pretty unsure if the backup would still be up-to-date by the time the primary server crashes.

> When talking with other postgres users about backups, we also found that primary and backup servers often run in a single data center or at a single (budget) provider. In effect, exposing these users to non-neglible risk of loosing database+backup.

There's some - obvious - challenges in getting new users to trust you enough to send them their database copy. At the same time, people host very sensitive data at (virtual) budget servers without thinking twice. What do you think?

Haha, thanks. It's just a dummy database with random data :).

But they're simple. Both for users and developers. Also, bots offer a very familiar UI pattern. And a chat log is suitable (but not ideal) for a lot of things. (See slack integrations)

It's going to be interesting to find out if/when tailored user interfaces can actually beat the log. (And too what degree platforms such as fb messenger will offer extensibility).

Disclaimer: Happening co-founder, we obviously gamble on the tailored interfaces.

Even more so, please prevent expensive TLS setup roundtrips to two different hosts. That's probably 2x as expensive as a single preflight request for non-resuming sessions.

As parent states: a simple reverse proxy is probably the way to go here. Takes about 3 lines in nginx.

> After reading a great blog post and MDN’s CORS docs I realized there are circumstances where the browser does not make a preflight request, if conditions are met

I must say I was a bit surprised that some POST requests can be executed without verifying CORS. There must be a bunch of POST endpoints out there that do have side-effects based on the cookie value, even without body. The distinction in behaviour between json or form encoding is pretty bizarre imo.

Rollbacks (canceling a transaction) on other systems usually take longer because it physically needs to rewrite the "undo log" back to the data pages.