It looks like this has SSL configured and listening, but there is no certificate or private key loaded:

  [~] : openssl s_client -connect 54.243.85.55:443                                                             
  CONNECTED(00000003)
  140150585800568:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:769:
  ---
  no peer certificate available
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 7 bytes and written 201 bytes
  ---
  New, (NONE), Cipher is (NONE)
  Secure Renegotiation IS NOT supported
  Compression: NONE
  Expansion: NONE
  No ALPN negotiated
  SSL-Session:
      Protocol  : TLSv1.2
      Cipher    : 0000
      Session-ID:
      Session-ID-ctx:
      Master-Key:
      Key-Arg   : None
      Krb5 Principal: None
      PSK identity: None
      PSK identity hint: None
      Start Time: 1486834426
      Timeout   : 300 (sec)
      Verify return code: 0 (ok)

Yes, there were some problems due to certificates and they are updated for API server now. Thank you for your interest!

I'm not sure this solves a real problem developers have. I have never heard from anyone that storing key/values was a pain.

A wide range of popular key/value stores exist and are easy enough to manage. Cloud provider also offer cheap managed stores.

I never had the need to store key/value pairs, but I would definitely consider a similar service. Why not?

Typo in the terminal screenshot:

> http://api.keyvalue/xyz/c98ab8e0/myKey

`api.keyvalue/xyz` vs. `api.keyvalue.xyz`

Fixed, thanks!

>Do you need high available, flexible and dynamic key/value store for coordination, notification, feature flagging and more?

Doesn't exactly evoke confidence. Are they being explicit that the free tier won't have availability. Is there an SLA or even an estimate?

Thank you for pointing this out! I have already updated the text for enterprise setup because that was not the intention.

SLA is in progress but the system is planned to be up & free with the current usage.

Where are the docs? SLA? Support for more complicated data? Support for WebSockets to alleviate TCP handshakes?

Add SSL. With LetsEncrypt, it's table stakes.

If they don't know this much, what else don't they know? Not to mention they don't disclose anything about the team or company other than it is "Made with Love in Istanbul". No reason not to assume its a kid who has never hosted a production service in their life.

Exactly. Instead I would totally code up my own self hosted key/value store in a couple of hours than trusting this website.

This. I'm kinda surprised there isn't HTTPS with HSTS already.

Since each new key request creates a uuid, wouldn't someone need to store that uuid in local key/value store in order to retrieve values from this k/v?

$ curl -X POST http://api.keyvalue.xyz/new/key1 http://api.keyvalue.xyz/3b629f4d/key1

$ curl -X POST http://api.keyvalue.xyz/new/key2 http://api.keyvalue.xyz/3eea0e2c/key2

I guess their primary target isn't generating keys on the fly, but rather using already defined keys (set / get value). But I agree, it would make sense to have the ability for reusing an existing UUID.

Is this a joke or for real?

I just ran a script to store about 20 keys/second and the counter is going up by 1-2 per second. Something is way off.

I have a few questions:

- how long will my data be stored for?

- how big can a single key be?

- how many requests can I make per hour/day?

Also consider jsonbin, a "pastebin for JSON" service. The aim of the project is to provide a simplified data store for tinkerers.

https://jsonbin.org/

Good site! Thank you.

It feels like this is a missed opportunity to use a content-addressable store. It would be super valuable to have the capability of hashing content and knowing when you don't need to re-download it.

Is there a way to batch requests? I'd like to be able to get/set more than one value at a time. It'd also be nice to be able to get a list of all my keys just in case I forget.

A web front end to memcache? I wrote one in Python 5 years ago. This is trivial stuff, although configuring your nginx proxy or whatever, takes some study. SSL can have 0 security if you do it wrong. I like the HIPAA advice from here https://luxsci.com/blog/level-ssl-tls-required-hipaa.html

I think this shouldn't be used to store application or user data, but could be actually useful for less important data used by cron scripts and scheduled jobs for which you would otherwise use a small local database or text files.

Any advantage over firebase?

Didn't a similar service just shut down recently due to lack of profitability?

So this is basically CouchDB?

But without TLS?

My thought too :-P could be a redis though with a rest API

supports CORS?