Cool site! but:

Get an SSL certificate so you serve over https https://letsencrypt.org/getting-started/

"But I don't need a SSL...." Here's Why Your Static Website Needs HTTPS https://www.troyhunt.com/heres-why-your-static-website-needs...

Looks like SSL is supported, they just don't auto upgrade requests.

During tests, we found it was better to let people chose.

You can use whatever method you feel more comfortable with.

Sometime usability and security go in different way. We could do HSTS but if you took time to type http:// maybe you really want http not https

Why is it better to let people choose? That implies there is a downside to https:// or a reason some people prefer http:// -- can you elaborate?

If you type just the domain name you get http:// by default, which, in my experience, is how most people type in site URLs.

People have their reasons, we respect that. But a default to https, why not? It seems reasonable to me.

I am not sure on how to get https:// by default while still supporting http:// for people who prefer it. It may take some advanced 302 redirect.

We will investigate and see what we can do there. Suggestions are much appreciated.

I'm still very unclear on a legitimate use case for this, and personally wouldn't do it until I had a good reason.

That said, a couple ideas on how to implement:

* Use an alternate domain, eg `insecure.domain.com`

* Use an alternate path prefix, eg `domain.com/insecure/` -- your app would have to be able to handle this

* Use a parameter that sets a cookie that your load balancer/reverse proxy can understand, eg, `http://domain.com/?https=false`, and will prevent redirect -- definitely the most complex from the proxy point-of-view, but means the URL (other than the scheme) is consistent for both types of user

I sometimes parse web data with uC based devices that are not capable of doing https with the memory space available. I appreciate the ability to use http when I need to.

I use http from embedded devices that cannot do https due to memory constraints. Http access is appreciated for this use case.

But.... Do you guys have a business model that is going to keep you around long enough for me to bother hardcoding your api into embedded devices? I build things that connect real world actions to cryptocurrency markets, diverting power, metering resource consumption, etc.

Please get in touch by email if you need something more than the free API.

For your embedded devices, we can make something special just for you

I use http from embedded devices that cannot do https due to memory constraints. Http access is appreciated for this use case.

But.... Do you guys have a business model that is going to keep you around long enough for me to bother hardcoding your api into embedded devices? I build things that connect real world actions to cryptocurrency markets, diverting power, metering resource consumption, etc.

We plan to remain online for a long long time

And if you make embedded devices using our API, maybe you need more than the free API?

We sell access based on subscription for 0.1 BCH per month.

Or maybe you need our 'special services'?

From the FAQ: "I'm wealthy. I have very specific crazy needs!"

"For the right price, the above rules may not apply to you. Right price means at least 1 BTC. If you can pay that, we can do many crazy things just for you"

Oops wrong place, sorry.

No wrong question :-)

Please get in touch by email if you need something special.

If you have hard constraints, we can provide you with a special API returning only the value(s) you need so you do not even have to parse anything.

GraphQL :)

Not attempting to be snide, this sentiment echoes exactly what GraphQL solves.

Co author here - I make the API and the backend.

The numbers come from a large sample of exchanges, with several million new datapoint added every day to cover every crypto we find important.

It is more of a hobby for me, but I hope you like it!

Hi 1996 - I used to work at [Cryptopia](https://www.cryptopia.co.nz/), a exchange fairly well known for listing low marketcap coins.

If you ever decide you want to expand to more than top 50 coins, then I'd love to help in any way I can - particularly with their API - feel free to email me: "james" at $my_hackernews_username ".nz"

Hi Scaur!

We are on #1 page!! Big surprise !! Now I have to reply to all questions but HN tell me 'you are posting too much'

I must fix bugs first, but I will be happy to email you!! I love cryptopia and it's approach!! Our email is in the faq: [email protected]

There is more on the website than the eye can see now. We will unveil new features soon.

Expanding beyond top #50 is something we want. We want to support more coins, and there is work in progress on that.

But after noticing what coins it will expose, we almost changed our mind and decide to just be top20.

After hard thinking, we decided to spend much more effort on methods to flags suspicious coins. Because there are many small promising coins that can benefit from exposure.

It is almost there. More algorithms to make!

The real work is to spot the anomalies, so your averages don't deviate from real values and I think that's what makes Coinmarketcap reliable.

If you say you made it for hobby, how are you trying to replace Coinmarketcap?

1996 is rate limited on the replies, so I'll answer: Until it brings in more money than it costs to make, it is a hobby.

I hope we grow and replace coinmarketcap. But that will take hard work, and lots of luck.

We have algorithms to spot anomalies. We want to offer extremely reliable data.

>The numbers come from a large sample of exchanges

Disclose the method and source

"average price on last calendar"

Average is a bad function to minimize error between expected values and actual values. Use median or median of the 5%-95% percentiles.

Indeed, the median works better in general, even on degenerate distributions. The Cauchy distributions has no defined mean, but still has a median.

We need to upgrade the FAQ to be more specific with the methods we use.

To be quick: The price come from many exchange. We exclude suspicious points. Then we do aggregation function like the average.

Averaging may not technically be the best method, but it is simple, and it has a wide support. And with the number of data points we have, we assume the Law of Large Number apply.

Still it could be interesting to use the median. I need to think more about it.

>we assume the Law of Large Number apply

Null hypothesis mandates you make no such assumption. Even if you did, a gaussian distribution assumes variable independence which markets are most certainly not. Even still if the variables were independent, you surely don't have enough samples of prices to report an accurate mean.

Agreed. We should not make such assumptions, because the number of exchanges is still quite low.

But you would be surprised to know how many samples we have at any moment!

I'd love historical API access!

We are split on that.

We would like to offer historical API to paying customers. We have a lot of data.

But we want to retain customers. We do not want them to leave after dumping our data. At keep keep paying us :-)

So we came to the conclusion: you get data from when you start to pay us, and we add a little extra (last 2 months) but no more. It is in the FAQ.

Historical API, we must think more about that.

You could offer historical data for a 1 time fee.