Blake3 is 10 times faster than SHA-2 - <AUTHOR> https://nextjournal.com/mk/BLAKE3 <comment><USER2> A lot of people in the comments are wondering about using SHA-2 vs Blake3 for password hashing. The answer is, neither of these is suitable by itself for password hashing. Sadly there's still a lot of advice on the internet (and, sadly, real systems) which do things like store md5(password) in a database and call it a day.

Blake2/3, SHA-2/3, and other cryptographic hash functions are meant to be _fast_ , while also effectively guaranteeing no collisions or any way of reversing the hash (pre-image attack). This makes them ideal for stuff like checking file integrity, message authentication, inputs for cryptographic signatures and the like. But since they're meant to be fast, they're very poor choices for hashing low-entropy data such as passwords - attackers can test vast numbers of passwords (even if you salt!!) on GPU hardware.

For low-entropy data, you want a hash function that is slow and hard to parallelize. Use a specialized password hashing algorithm like bcrypt, scrypt or Argon2, and tune it so it's slow enough without impacting overall usability (e.g. takes 50ms on your server). These algorithms are resistant to parallelization, so attackers will only be able to test a small number of passwords per second. This slows attackers down and can prevent them from recovering passwords that might be recoverable if stored using SHA-2, etc.

<comment><USER3> This is a good time to ask for a question I have always wondered about these slow hash functions: are they slow because they are computationally intensive or is it that they have other tricks that makes them slow without costing too much load on your server (like needing RAM access, syscalls or anything that add latency but not much CPU load). If it's the former, isn't it a good DOS target, making your server busy hashing random crap and unable to process other requests?

<comment><USER4> > are they slow because they are computationally intensive...

In general, no. Most "slow" hashing schemes are designed to be memory-hard and highly serial (more threads = more contention, not throughput). Some of the earlier approaches just try to maximize computational requirements, but modern research acknowledges the march of computing power makes that an inherently poor choice for long term sensitive data. Argon2 is just one of the more advanced versions of a memory-hard scheme, building on prior research. I could try to give a poor explanation, but instead I'll link you the spec which is very readable: [https://github.com/P-H-C/phc-winner- argon2/blob/master/argon...](https://github.com/P-H-C/phc-winner- argon2/blob/master/argon2-specs.pdf)

<comment><USER3> Thanks!

</comment></comment></comment></comment><comment><USER5> JP Aumasson just announced Blake3 at Real World Crypto a few days ago during the lightning talks. This was also right after he presented on "Too Much Crypto"[1] which argues that we use too many rounds in symmetric constructions: our security margins are too high and don't match any of the best "practical" attacks. We're too paranoid for our own good. He suggests reducing the number of rounds for a number of constructions like AES, SHA-3, Blake2, etc.

[1]: [https://eprint.iacr.org/2019/1492.pdf](https://eprint.iacr.org/2019/1492.pdf)

Blake3 is in part a reduction of number of rounds (so it's faster), it's also a bit of a design change (the round function, and the parallelization), and it's now just one multi-purpose function (instead of several instances) that takes an arbitrary-length input and gives an arbitrary-length output.

My questions are:

* what are standards using Blake2 (like Noise) going to do?

* what do cryptanalysts think?

* is it really that fast? (I'll have to benchmark this for my own use-case.)

<comment><USER6> > which argues that we use too many rounds in symmetric constructions: our > security margins are too high and don't match any of the best "practical" > attacks. We're too paranoid for our own good. He suggests reducing the > number of rounds for a number of constructions like AES, SHA-3, Blake2, etc.

This seems a quite dangerous way of thinking. New attacks, methods to attack crypto are discovered regularly. A view years ago people also said SHA-1 will never get broken to the degree it just got broken a recently.

 __So the only think we can do is to be slightly paranoid, everything else would be strongly negligent __.

Especially if we consider how long it often takes in practice to update software and phase out previous encryption and hash methods without having to worry about e.g. downgrade attacks or similar.

Sure software should be possible to be updated asap, but honestly how long will it take until SHA-1 is phased out?

EDIT: Through that also means if you believe you will always be able update the _deployed_ relevant parts of your software ASAP (which can't work for libraries) and you are sure that you will follow the crypto community close enough and you believe some one else does so to if you are unavailable because of sickness, then yes go ahead and use less paranoid/secure crypto.

<comment><USER7> _This seems a quite dangerous way of thinking. New attacks, methods to attack crypto are discovered regularly._

It's not, really, because there is obviously _some_ security margin that is too high. It makes a lot of sense to consider and try to quantify what that is. If all we have is some vague 'well, there are always new attacks' then how do we know the current margins are enough? Why not double the rounds, crank up the hash sizes, etc? It's not really a meaningful response to Aumasson's work.

<comment><USER8> 1\. As a community: Because you have to balance cost and security. Maybe we could increase them a bit without it stinging too much. But we can't do it boundlessly.

2\. As an individual: Because I'd probably mess it up and pick a number of rounds that is e.g. divisible by 23 which weakens the system for some number theoretical reason that's far beyond my understanding.

</comment></comment></comment></comment><comment><USER9> This is a bit pointless, since it does not say on which platform the comparison is made.

In any case, KangarooTwelve [1][2] (on AVX-512) is also 10x faster than SHA-256.

KangarooTwelve is a fast hash function of the Keccak family (from which the SHA-3 derives from), and it is clearly what BLAKE3 tries to catch up with.

However, KangarooTwelve probably benefits from the more extensive scrutiny that SHA-3 has received and will receive, and (from a performance standpoint) from future HW extensions that will speed it up even more (the first one appeared on ARMv8.2).

[1] [https://keccak.team/files/KangarooTwelve.pdf](https://keccak.team/files/KangarooTwelve.pdf)

[2] [https://www.cryptologie.net/article/393/kangarootwelve/](https://www.cryptologie.net/article/393/kangarootwelve/)

<comment><USER10> There is a comparison of Blake3 to various hash functions (including SHA-2 and SHA-3 families) on AWS c5.metal; see the chart here: [https://github.com/BLAKE3-team/BLAKE3](https://github.com/BLAKE3-team/BLAKE3)

<comment><USER9> Yes, and it didn't go unnoticed that KangarooTwelve (which - mind - does not belong to the SHA-3 family right now) is not included on that prominent comparison diagram, while it is considered in the BLAKE3 paper.

<comment><USER11> I felt it would've been unfair to include KangarooTwelve in that particular bar chart, because at 16 KiB of input it hasn't reached its peak throughput. At the same time, the goal was to focus on more widely used algorithms.

</comment></comment></comment></comment><comment><USER12> Speed comparison from the BLAKE3 authors: [https://github.com/BLAKE3-team/BLAKE3/](https://github.com/BLAKE3-team/BLAKE3/)

I hadn't heard of BLAKE3 before (I thought BLAKE2b was the latest and greatest), judging by commits from the repositories of that user it's about half a year old now.

Paper's abstract starts with:

> BLAKE3 [is] an evolution of the BLAKE2 cryptographic hash that is both > faster and also more consistently fast across different platforms and input > sizes. BLAKE3 supports an unbounded degree of parallelism, using a tree > structure that scales up to any number of SIMD lanes and CPU cores. On Intel > Cascade Lake-SP, peak single-threaded throughput is 4× that of BLAKE2b, 8× > that of SHA-512, and 12× that of SHA-256, and it can scale further using > multiple threads. BLAKE3 is also efficient on smaller architectures [like] > 32-bit ARM1176

In the introduction, the reason for BLAKE3 is described:

> A drawback of BLAKE2 has been its large number of incompatible variants. The > performance tradeoffs between different variants are subtle, and library > support is uneven. BLAKE2b is the most widely supported, but it is not the > fastest on most platforms. BLAKE2bp and BLAKE2sp are more than twice as fast > on modern x86 processors, but they are sparsely supported and rarely > adopted. BLAKE3 eliminates this drawback. It is a single algorithm with no > variants

Paper: [https://github.com/BLAKE3-team/BLAKE3-specs/](https://github.com/BLAKE3-team/BLAKE3-specs/) (By the way, the download doesn't work for me in the latest Firefox on Linux and GitHub's rendering is plain awful. Not sure if anyone else can reproduce that or if my Firefox is broken.)

<comment><USER13> The reason you haven't heard of it before now is that it was released 2020-01-09, last Thursday at the time of writing, at Real World Crypto.

<comment><USER12> The only author of BLAKE3 that spoke there was JP (@veorq). The day matches but the title of his talk is "Too Much Crypto". Is that where it was announced? (Quick link to program: [https://rwc.iacr.org/2020/program.html#day-2020-01-09](https://rwc.iacr.org/2020/program.html#day-2020-01-09))

<comment><USER14> It was announced in a lightning talk following that session

<comment><USER12> That doesn't sound very official. Most text in the paper seems to date from August, so it looks like this has been out for a while and was not only just announced, even if it was mentioned or officially "announced" (while being already released) in a surprise talk at that conference.

<comment><USER11> JPA and I announced BLAKE3 at the RWC lightning talks, after JPA's Too Much Crypto talk, and we published all the repos and crates.io packages about 30 minutes prior to that. The commit history that you see in the repos was private until January 9.

</comment></comment></comment></comment></comment></comment><comment><USER15> Do the runtime tests decouple from I/O times e.g. file and memory caching aren't affecting the results?

Surprised because I'd expect a big file like that to be I/o bound in practice

<comment><USER16> There is a tech talk about Bao (I think it's the same author) where he prefaced the talk by describing a few caveats like "benchmarks are lies" and he mentioned that you should always run a timed process a second time to tease out bias from cached/pages instructions and data.

The core reason this method is faster than traditional SHAs is because Blake3 is a binary tree where the leaf blocks can be hashed in parallel and SHA is entirely sequential

<comment><USER12> > you should always run a timed process a second time

I should hope that anyone doing benchmarks does them multiple times to avoid crap like popcon or adobe reader update randomly keeping the system busy during one of the two algorithms' benchmarks. I don't expect that the author ran this only once and decided to make a blog post based on that, even if the post doesn't show multiple runs.

<comment><USER17> Author here, I did run it a few times but you don't have to take my word for it, you can rerun the notebook yourself if you sign up for Nextjournal and remix my notebook. Full disclosure: I'm also a Cofounder of Nextjournal.

But I wouldn't suggest to use Nextjournal for serious benchmarking (yet). We're running on Google Cloud and it's not suited for benchmarking unless you pay for a (big) sole tenant instance. In the future we plan to offer dedicated instances for benchmarking.

</comment></comment></comment></comment><comment><USER18> Is "faster" always a good thing in hashing algorithms?

Suppose a hashed password database falls into wrong hands. If they're hashed with a faster algorithm wouldn't it be easier to try a dictionary attack to discover the real passwords?

<comment><USER19> You can always make a fast hashing algorithm into a slow-enough password hashing algorithm by repeating it multiple times (as with PBKDF2) or better yet using a construction that also uses a minimum amount of memory, not just computational time. For most cryptographic applications (signing data in transit, signing data at rest, computing things like Merkle trees for applications like git and dm-verity), you want a hash that is fast to compute. It's basically only password hashing and cryptocurrency mining that needs to be slow.

BLAKE3's readme says: ([https://github.com/BLAKE3-team/BLAKE3](https://github.com/BLAKE3-team/BLAKE3))

 _NOTE: BLAKE3 is not a password hashing algorithm, because it 's designed to be fast, whereas password hashing should not be fast. If you hash passwords to store the hashes or if you derive keys from passwords, we recommend Argon2._

Argon2 ([https://github.com/P-H-C/phc-winner- argon2/blob/master/argon...](https://github.com/P-H-C/phc-winner- argon2/blob/master/argon2-specs.pdf)) is based on BLAKE2b.

</comment></comment><comment><USER20> I don't think it's a coincidence that BLAKE3 has been released shortly after the latest SHA-1 news. Many SHA-1 users would rather avoid the performance impact of SHA-2/3.

</comment><comment><USER21> Reducing 10 rounds in Blake2 to 7 in Blake3.. huh?

The entire industry is going in exactly the opposite direction of this, to increase the complexity and depth of the attack surface of cryptographic methods and algorithms due to advances in quantum computing. Cloudflare, Microsoft Research etc are all investing heavily into post-quantum cryptography technologies, almost exactly the opposite of what this guy is promoting. Makes no sense. ‾\\_(ツ)_/‾

</comment><comment><USER22> This is completely pointless, but there's so many random things I share a name with, and somehow I've only met a few PEOPLE named Blake in real life.

</comment><comment><USER23> What are the criteria for choosing an integrity checking hash? Speed is always desired, and longer output makes collisions due to random bit swaps less likely.

Even CRC32 is still used in embedded systems for short pieces of data.

Is there anything else important for detecting transmission errors if the data was sent encrypted, or is something like MD5 still sufficient for such uses?

Is Blake3 even worth considering for such a use case?

<comment><USER24> Never use MD5 except for compatibility.

<comment><USER12> This. There are hash functions that are faster than MD5, so it's not the fastest, and everyone knows (since 1996, actually[1]) that MD5 is insecure.

If you want transmission error checking, use CRC32 or Siphash or whatever. If you want an actual, cryptographic hash function, then BLAKE3 is one of the options, though it's a very young one so unless you really know what you're doing, you should probably not use this for another few years. Heck, if anything in this comment is new to you, you'll want to steer clear of such low-level decisions and just use a library that makes the decision for you.

[1] [https://en.wikipedia.org/wiki/MD5](https://en.wikipedia.org/wiki/MD5) "In 1996, Dobbertin announced a collision of the compression function of MD5 (Dobbertin, 1996). While this was not an attack on the full MD5 hash function, it was close enough for cryptographers to recommend switching to a replacement, such as SHA-1 or RIPEMD-160."

<comment><USER23> > Heck, if anything in this comment is new to you, you'll want to steer clear > of such low-level decisions and just use a library that makes the decision > for you.

This reads very condescending: I posed the question to learn something, not be told off.

<comment><USER12> I'm sorry, I hate it when others do that and don't notice when I do it myself apparently.

It was really just meant to be read in the literal sense and not as that such a person is of less value or stupid. It can easily (and has) lead to security breaches if assumptions are made about this. I'm not saying _you_ don't know the difference between md5 and crc32, but if anyone doesn't yet know that, then it's risky to make decisions about these things until they learn more. Cryptographers commonly advise non-experts to use a library to do things for you (even those that know a bit more) since cryptography can be very subtle, but clearly I should have phrased that better.

<comment><USER23> > Cryptographers commonly advise non-experts to use a library to do things for > you

On the high level, the problem is that libraries are usually "CRC32", "MD5", "SHA256", etc. There's no guiding resource that I have found that matches use cases to libraries, which is where the initial question comes from.

That is, unless you meant a library that covers the entire use case, but there isn't always one.

<comment><USER25> That's part of why NaCl, Libsodium, and Libhydrogen have the APIs they do: they cover secure ways to use the primitives, make those ways easy, and make it harder to misuse things. It's also why so many security professionals like the "noise" protocol: it doesn't leave any of the difficult choices open to be misused.

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> This benchmark is not a comparison between BLAKE3 and SHA-2, it's a comparison between b3sum and sha2sum. Things like file access pattern, hiding io latency, distributing work to cores, etc can make huge differences that have nothing to do with the hash functions themselves.

</comment><comment><USER27> Unless you have SHA-NI in your processor... in which case Blake3 is slower than SHA-2.

</comment><comment><USER28> I look forward to a future point in time where Blake7 is released.

<comment><USER11> [https://twitter.com/dchest/status/1215751501567709185](https://twitter.com/dchest/status/1215751501567709185)

<comment><USER29> 1978 isn't on the graph. (-:

Hint: andybak was making a joke.

<comment><USER11> Straight talk, should I watch this show? :)

<comment><USER30> A friend recently wrote a re-watch review: [https://nwhyte.livejournal.com/tag/tv:%20blakes%207](https://nwhyte.livejournal.com/tag/tv:%20blakes%207)

</comment></comment></comment></comment></comment><comment><USER31> I would like to see the performance of KanagarooTwelve in the same tree structure as BLAKE3, with AVX-512, on the same hardware (AWS c5.metal).

<comment><USER11> Take a look at Figure 3 in the Performance section of the BLAKE3 spec: [https://i.imgur.com/smGHAKA.png](https://i.imgur.com/smGHAKA.png). That graph doesn't account for differences in the tree structure, but it compares the performance of both with AVX-512.

</comment></comment><comment><USER32> Uhhh, I have an idea how sha-256 works but not blake3. Is blake3 better for storing passwords? If not, what is the go-to recommended hash for password storage of say, a simple front-facing app for consumers.

<comment><USER33> SHA-256 is absolutely not recommended for storing passwords, and it was never designed for that purpose. If you are storing passwords with SHA-256 you should immediately migrate them to a password hashing algorithm. See "Upgrading Legacy Hashes" in the link below.

[https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)

Recommended algorithms:

\- Argon2

\- PBKDF2

\- Bcrypt

</comment></comment><comment><USER34> Is it better in preventing hash collisions?

<comment><USER12> Compared to?

MD2, MD4, MD5, SHA-1, etc.: There are collisions known, so yes.

SHA-2, SHA-3, BLAKE2b, Skein, Whirlpool, etc.: We don't have any collisions for these, so it doesn't get any better than that.

<comment><USER35> > _SHA-2, SHA-3, BLAKE2b, Skein, Whirlpool, etc.: We don 't have any > collisions for these, so it doesn't get any better than that._

There are important differences; some of those primitives are definitely more trustworthy than others.

SHA-2 and Whirlpool use the old Merkle–Damgård construction, which has fallen out of favor because of unfortunate properties.

They are vulnerable to length extension attacks, such that it can be misused. For instance, if you want to use it as a keyed hash, you cannot just do sha2(key + message) (where + is concatenation). You have to use something like HMAC for that.

Skein is much better, but has a bit of an aged design now, and an insane 72 rounds. It doesn't have as much love as BLAKE2 for instance, which makes it unlikely that people will build things competitive with BLAKE3 with it.

SHA-3, BLAKE2b and BLAKE3 are the best. Like Skein, they are not vulnerable to length extension attacks, so they have a trivial keyed hash function construction.

SHA-3 in particular has an elegant new design, the Sponge construction, which yields precise cryptographic protections in terms of the number of bits of security. It has displaced Merkle–Damgård as The Way We Do Things™ now; many modern hashes use it, eg Gimli relied on it to make comparisons.

One of the great things about this form is that it makes it a XOF: you can make your hash as long as you desire. (BLAKE also shares this property, but with a different construction.)

However, SHA-3 is slow, so if you want speed, use BLAKE2b (or Kangaroo12) over SHA-3, and BLAKE3 over them both.

If you want to be conservative about security and don't care about speed, a safe bet is still SHA-512/256, which is safe against length extension attacks.

<comment><USER12> That was informative, thanks! It matched my gut feeling about the algorithms and I knew some of these things, but not everything :)

> a safe bet is still SHA-512/256, which is safe against length extension > attacks.

I would like to add here that this does not mean "SHA-512 or SHA-256" (I remembered that SHA-256 was not length-extension resistant and looked up the details). Instead, it means the version of SHA-512 that gets truncated to 256 bits. This is apparently relatively new (or at least added after I last read up on SHA-2):

> In March 2012, the standard was updated in FIPS PUB 180-4, adding the hash > functions SHA-512/224 and SHA-512/256, and describing a method for > generating initial values for truncated versions of SHA-512.

\-- [https://en.wikipedia.org/wiki/SHA-2#Hash_standard](https://en.wikipedia.org/wiki/SHA-2#Hash_standard)

I feel like that notation could have been chosen better by NIST.

<comment><USER36> The hash function "SHA-512/256" has different initial constants than "SHA-512", so it is not equivalent to truncating a "SHA-512" hash value.

SHA-224 and SHA-384 are somewhat resistant to length-extension attacks because they output a truncated state.

Yeah, the slash in the names are an unfortunate choice that hurts clarity.

</comment></comment></comment></comment></comment><comment><USER37> If you hash the password, and then use that hash as the key to encrypt(AES/ChaCha20) the original password it self, isn't this good?

</comment><comment> jagged-chisel I can write a fast digest algorithm. Doesn't mean it's safe for anything more than triviality.

</comment><comment><USER38> I have a project I couldn't use SHA-2 on because of speed and because it was a 224bit or 256bit result.

Is there a way to use Blake3 in a reduced hash result way? Like 12-16 byte results. (IIRC, you can not truncate hashes for smaller results)

<comment><USER39> SHA-224 is literally truncated SHA-256. There's no security proof this is safe, but only in the sense there is no proof SHA does what it claims to do at all. Hash truncation is in the design of SHA-2. There's even an appendix of one of the FIPS documents explaining how to do the truncation for arbitrary sizes.

But be very careful to make sure that you only need preimage resistance...

<comment><USER40> A 224 bit output is going to be collision resistant too, though, for the foreseeable future. And when it comes to preimage resistance, even md5 is safe for the time being. (With the usual qualifier that there's absolutely no justification for using it with better hashes available.)

<comment><USER39> He's talking about 12 to 16 byte outputs though, which is 96-128 bits of preimage resistance, and only 48-64 bits of collision resistance.. which would be very broken today.

<comment><USER38> Mostly.

There are 12-16 byte hash or hash-like results are plenty secure. They're keyed though.

The output from HMAC and AEAD ciphers with no encryption (think the additional data portion of ChaCha20-Poly1305 in a Nonce-MAC mode)... or maybe I'm wrong because these require nonces and keys.

<comment><USER39> Whether you are using it in a keyed authentication mode is orthogonal to collision resistance.

</comment></comment></comment></comment></comment></comment><comment><USER41> Not really. It's even 2x slower than SHA256-NI, the builtin.

b3sum is much faster than sha256sum, and blake3 is about 2x faster than blake2.

[http://rurban.github.io/smhasher/doc/table.html](http://rurban.github.io/smhasher/doc/table.html)

<comment><USER42> Not sure why you are downvoted. Your table looks more factual than the blake3's github.

<comment><USER35> RE: the downvotes; while I didn't partake, I know there is history between the BLAKE/BLAKE2/BLAKE3 author, JP Aumasson, and Rurban, in particular related to differing opinions over the publication of SipHash.

Differing opinions here means that most of the cryptographic community agree that SipHash clears its claims as a PRF, while Rurban indicated he has found undisclosed vulnerabilities that he wishes not to publish.

RE: the table; a point to note is that BLAKE3's main implementation, in Rust, benefits a lot from multithreading on large files, which SHA2 cannot. The C version, which Rurban copied, does not leverage multithreading: [https://github.com/BLAKE3-team/BLAKE3/blob/master/c/README.m...](https://github.com/BLAKE3-team/BLAKE3/blob/master/c/README.md)

<comment><USER43> Comparing single threaded speeds is also very valid for tons of contexts. Of course if one algo can't be multithreaded, maybe it will be better to use one that can instead, if that's interesting for a particular application, but it won't be _necessarily_ interesting for _all_ applications. So there is no single ordering about which is faster, in this case. If you sometimes needs to compute hashes on a computer that would have multiple unused cores at that moment, the multithreaded hash will have an advantage. If you are always loaded, you better consider the total amount of work; and maybe likewise if you want to prioritize energy efficiency (although it will not be completely linear)

</comment></comment></comment></comment><comment><USER44> I always shake my head when performance is touted for new functions/constructions. It's more important to minimize the costs of legitimate use while maximizing the costs of software and hardware attacks. Minimizing the former inevitably leads to minimization of the latter in brute force (cloud cluster, ASIC, FPGA, etc.) attacks. The fundamental impetuses of scrypt (a PBKDF rather than an unauthenticated hash function) was a righteous and necessary advance that must never be forgotten with each fashionable iteration of newness that seems to lose sight of how faster or newer isn't always automatically better.</comment>


Stripe and offshore companies with bank accounts outside of the States - <AUTHOR>

I wanted to create a Stripe account for my offshore company in the States (I live in Europe), the problem was my bank account assigned to this company is located outside the States (it's legal) and I wasn't able to create a Stripe account. I'm running my company 3 years and never had problem with any other payment processor. Stripe couldn't answer why I cannot do that except for the vague explanations. I came here so maybe someone reasonable will hear my voice and help me out with this "impossible" situation? <comment><USER2> A company that is based in the US without a US bank account might be a red flag to any payment processor. The easy answer is open a US based account for the business and have the funds transferred, however, there are likely some tax consequences you would have to explore.

Stripe isn't perfect, but my bet is that they don't get to make a lot of these types of decisions. From my understanding when you become a gateway/clearing house there are all kinds of rules Visa/Mastercard etc place on you. It is a risk profile that those "banks" define and Stripe and others must keep all their clients within the profile. So if you don't fit within that risk profile you are out of luck. Generally the risk profiles are the same at almost all clearing houses so you won't find a lot of differences, unless the company also has worked within your countries banking system too.

Paypal works differently than a traditional merchant gateway from my understanding as well they have worked through issues in other countries to be compliant letting them process credit card transactions natively in those locations. But with that comes some of the crazy things they do, like locking up your funds for months and trickling them out to you if your volume changes too rapidly, amongst other reasons.

Good luck.

</comment><comment><USER3> Using something else instead of Stripe seems to be the course of action that makes the most business sense. Maybe in the future Stripe will be a sensible option for your business.

Goid luck.

</comment><comment><USER4> try [https://www.braintreepayments.com](https://www.braintreepayments.com)

brain tree uses paypal account

[https://news.ycombinator.com/item?id=9786010](https://news.ycombinator.com/item?id=9786010)</comment>


Link Between Neanderthal DNA and Depression Risk - <AUTHOR> http://www.theatlantic.com/science/archive/2016/02/neanderthal-dna-affects-depression-risk-today/462345?single_page=true <comment><USER2> > the effect is subtle, explaining just 1 percent of a person's depression > risk.

That seems like noise to me. Especially in such a large study that attempted to cross-correlate (apparently) hundreds of factors, I would require a _lot_ more evidence not to discard this as the jelly bean effect ([https://xkcd.com/882/](https://xkcd.com/882/)).

Now I haven't read the paper, but based on this article, I dare say it would be irresponsible to label this a finding.

<comment><USER3> In addition, even if there is a real effect here, it is so small, and the interactions so complex, that it's probably useless.

For example, even if this neanderthal gene happens to causally affect depression by 1%, that pathway might be something like

gene => slightly wider shoulders => that body structure is slightly more or less likely to lead to certain life outcomes, like marrying early or getting promoted or getting targeted by pickpockets => change in depression risk

As a result, the gene might currently lead to a 1% increase in depression risk, but in a few years it might do the opposite, if things change in the surrounding culture and those intermediary steps behave a little differently.

</comment></comment><comment><USER4> > Some headlines will inevitably claim that we can blame Neanderthals for > depression, but that's nonsense.

Says the article titled _Link Between Neanderthal DNA and Depression Risk_.

</comment><comment><USER5> "They started with 13,700 people from the eMERGE Network, and looked for associations between 135,000 Neanderthal genetic variants and 1,689 different traits."

Does anyone know how they compensated the statistics to control for the p-hacking?

<comment><USER6> I took a brief look at the paper scanning for multiple hypothesis testing corrections.

"Neandertal variants have been hypothesized to influence many phenotypes in AMHs, including lipid metabolism, immunity, depression, digestion, hair, and skin, on the basis of the enrichment of Neandertal variants in regions of the genome relevant to these traits. Accordingly, we first tested these hypotheses using genome-wide complex trait analysis (GCTA) to estimate the phenotypic risk explained by 1495 genotyped common (minor allele frequency > 1%) Neandertal SNPs for a set of 46 highprevalence phenotypes from the hypothesized categories, using age, sex, and eMERGE site as covariates."

When testing these 46 traits they controlled the FDR < 0.05 (false discovery rate). Then they replicated the associations in an independent sample.

The effect sizes are pretty small (1-2%), so having the explanatory variants won't have much bearing whether or not you'll get these complex traits.

<comment><USER7> Was the _only_ correlation that survived FDR control and the validation set?

I'm also curious as to why ethnic origin wasn't a covariate.

</comment></comment></comment><comment><USER8> Even Darwin had noticed this, when he described the differences between groups which (unbeknownst to him) had Neadenthal origins and those who don't.

"There is however no doubt that the various races when carefully compared and measured differ much from each other as in the texture of the hair, the relative proportions of all parts of the body, the capacity of the lungs the form, and capacity of the skull, and even in the convolutions of the brain. But it would be an endless task to specify the numerous points of difference. The races differ also in constitution in acclimatisation and in liability to certain diseases. Their mental characteristics are likewise very distinct chiefly as it would appear in their emotional but partly in their intellectual faculties. Every one who has had the opportunity of comparison must have been struck with the contrast between the taciturn, even morose, aborigines of S. America and the light-hearted talkative negroes."

And to think, some fundamentalists want to ban discussion of Darwinian evolution.

<comment><USER9> You'll be depressed too... Once the transhumanists are successful in their plot to rule the entire planet, while they constantly insist on using "Homo Sapien Sapiens" as a colloquial derogatory term for "those intellectually- challenged violent brutes" ;)</comment></comment>


Greece buys 500 M1A1 from the US - <AUTHOR> http://www.defencegreece.com/index.php/2011/10/the-u-s-approved-to-grant-400-m1a1-abrams-to-greece/ Hard to believe where the money is from - ahh, a credit from the US. Is it the same Greece that has a problem with its credits? And the US, don`t they have a problem with their deficit? Sorry, i forgot, WEAPONS! <comment><USER2> Greece didn't buy them, the US granted them. For free, as far as I can tell.

<comment><AUTHOR> As far as I understood does the US government pay the money directly to the company building the tanks - i call this a subsidy, grant sounds much nicer. Buying and selling or exporting and importing on credit - isn`t this in the core of the worldwide financial crisis?

<comment><USER2> If it were a loan, I would only be curious why Greece wants 400 really nice tanks. But a grant doesn't have to be paid back like a loan does, so it's not "on credit". So now I'm curious why the US want Greece to have 400 really nice tanks?

<comment><AUTHOR> Call my meticulous but isn`t it the same? The US government pays the company that build the tanks, so it is a loan on the American people.

<comment><USER2> I don't see how it's a loan at all. The grant will never be repaid. The US just gifted them a bunch of tanks (or money, however you look at it). If it's a loan, who has to pay back?</comment></comment></comment></comment></comment>


Show HN: A fireplace for Emacs - <AUTHOR> https://github.com/johanvts/emacs-fireplace <comment><USER2> This could be made more fun, by using more system resources so your laptop heats up too!

<comment><USER3> The first Twitch office (back when it was Justin.TV) was so cold I wrote a "heater" command for my macbook. It just spun the cpu in a tight loop, and was very effective!

<comment><USER4> I had a Mac Pro under my desk for a while. If I had done that, I'd have third degree burns.

</comment></comment></comment><comment><USER5> The README's linked Emacs animation guide is compact and informative: [http://dantorop.info/project/emacs- animation/](http://dantorop.info/project/emacs-animation/)

</comment><comment><USER6> > see title

> think to myself "Oh, did someone port Vim-fireplace to emacs? But why? Must > be for fun, let's check it out"

> see repo

> "Emacs users"

<comment><USER7> > Oh, did someone port Vim-fireplace to emacs?

They did! And because Emacs has a time machine module, they did it before vim- fireplace existed, the bastards!

<comment><USER4>
        C-t M-u C-M-S-y <year>

For those of you without Emacs experience.

</comment></comment></comment><comment><USER8> Which reminds of the Yule Log TV program[1] for those who lived in the NY metro area < 1990\. Although it seems farcical now, it was envisioned as a way for low-income residents without a fireplace to have a "fire" during the Christmas holiday.

[1] [https://en.wikipedia.org/wiki/Yule_Log_(TV_program)](https://en.wikipedia.org/wiki/Yule_Log_\(TV_program\))

<comment><USER9> That name - the Yule Log - seems familiar, and brings up some vague but soothing memories for me. I believe it was an early Internet (i.e. circa 2000, "Web 1.0") web page that displayed the same kind of fireplace-log setup. Gave me some serene, hypnotic peace in the midst of the excitement of programming in Borland Turbo-C!

<comment><USER10> Yule logs are rather older than the Internet:

[https://en.wikipedia.org/wiki/Yule_log](https://en.wikipedia.org/wiki/Yule_log)

</comment></comment></comment><comment><USER11> Very neat! :-)

Unfortunately, I'm having a little problem "regulating the heat": C-+ is supposed to make the fire bigger, C-- smaller. When I run this in a tty, neither of the two does anything. When I run it under X, C-+ moves the fire down and C-- moves it up. Is it just me or is that a bug? (Running elementaryOS Freya.)

<comment><AUTHOR> Thanks, it is the intended behavior. It has been useful for me a few times when the fire didn't align properly. There is no function for making the fire bigger and smaller yet.

<comment><USER11> Well, de facto it can make the fire bigger or smaller. If the bottom of the fire is below the lower screen edge, only a small part is visible. Move the fire up -> more becomes visible -> the fire becomes "bigger" ;-)

At least is does in a graphical environment. Like I said, it doesn't work in terminal.

</comment></comment></comment><comment><USER12> Ahh yes good 'ole M-x fireplace

<comment><USER13> I typically just use C-x M-c M-butterfly to cause a raging firestorm. Then just grab a burning log from there.

</comment></comment><comment><USER14> Every program attempts to expand until it can display a fireplace. Those programs which cannot so expand are replaced by ones which can.

</comment><comment><USER15> I love it. I feel nice and cozy while I hack now.

<comment><USER16> just missing the cracking sounds :)

</comment></comment><comment><USER17> This is pretty much the best thing ever.

</comment><comment><USER18> There is a beautiful world out there.

Go explore.

</comment><comment><USER19> emacs's shell + cacafire anyone? :)

Edit: ok, I tried what I said. Not that great. Frame rate is really too low.

Edit2: [http://imgur.com/a/g0JYu](http://imgur.com/a/g0JYu)

</comment><comment><USER20> I keep getting weird issues when running it. [https://s3.amazonaws.com/coda- files/870Xw.png](https://s3.amazonaws.com/coda-files/870Xw.png)

<comment><USER21> Turn off visual-line-mode, maybe? The fringe shows line wrapping indicators, which probably isn't good here.

<comment><USER22> I'm getting something similar. Turning on truncate-lines fixed it.

</comment></comment></comment><comment><USER23> This is a great start!

I think we can do even better, though. Only two colours? Only using solid blocks? We should be able to get beautifully smooth 256x256 (dithered) colour!

</comment><comment><USER24> Just what I needed to complete my auto heating laptop. This animation will compliment the buzzing laptop fan with heat, so I enjoy some warmth this winter.

</comment><comment><USER25> This is why I visit Hacker News every day! Love it.

</comment><comment><USER26> Any chance you could add a license? Very neat! :)

</comment><comment><USER27> Missing license information?

<comment><USER28> Placing legal paperwork next to a fireplace never ends well.

</comment></comment><comment><USER29> Top that, Vim.

</comment><comment><USER30> Cool, now ... make mcedit do this!

</comment><comment><USER31> Ah, another use for emacs besides Tools > Games > Tetris.

</comment><comment><USER32> finally a good use for logs!

</comment><comment><USER33> Ok, someone has to say it.

Why.

<comment><USER34> You must be a vim user...

In seriousness though, why not? He probably had a good time writing it, learned a thing or two, and now has something fun to show off. "Why" doesn't need an answer if it's fun. Besides, the odds are that "hey, look at how this code makes a fireplace" will get someone interested in coding who was bored by "hey, look how this code lets me manage a large database of packages."

<comment><USER33> I'm a vim user who's trying to convert, actually. So, as a demonstration of elisp, this is cool — but why would anyone actually install this package?

<comment><USER35> To play with it for 30 seconds and then forget about it. Or to show it to friends at work. Or for any number of silly reasons. Personally, I'm interested in the code - I don't know how to do that in Emacs, and I wish I would.

</comment></comment></comment></comment><comment><USER36> Amazing!

Have they ported a good text editor to Emacs yet?

<comment><USER37> They sure have, it's based on this weird old editor called "vim" [https://bitbucket.org/lyro/evil/wiki/Home](https://bitbucket.org/lyro/evil/wiki/Home)

There's even an emacs distribution built around it [https://github.com/syl20bnr/spacemacs](https://github.com/syl20bnr/spacemacs)</comment></comment>


Eating Leafy Greens Each Day Tied to Sharper Memory, Slower Decline - <AUTHOR> https://www.npr.org/sections/health-shots/2018/02/05/582715067/eating-leafy-greens-daily-may-help-keep-minds-sharp <comment><USER3> Nothing like chopped & steamed spring greens topped with west indian hot sauce, a little mayo and some pepper. Mmmmmmm

</comment><comment><USER4> This is an observational study. Observational studies in the field of nutrition have a _horrendous_ track record; this research is almost no evidence at all for its finding.

<comment><USER5> I agree, the article did a poor job of elucidating leafy greens role in enhancing memory. Allow me to suggest a more plausible mechanism of action for this effect:

Leafy greens contain more magnesium than other sources due to its presens in the cholorphyll structure. The glycolytic cycle also requires magnesium for enzymes [0], so one might expect the memory enhancement effect to be more likely the result of additional glucose avalibility [1]. Additionally, alcohol consumption can cause a magnesium deficiency by diuretic effect - <USER2> the glycolytic cycle and resulting in poor memory retention when deficiency occurs.

Although soluable magnesium supplements work in the same way, I'm currently testing agricultural methods of increasing Mg2+ levels in leafy greens.

[0] [https://www.ncbi.nlm.nih.gov/pubmed/2931560](https://www.ncbi.nlm.nih.gov/pubmed/2931560) [1] [https://www.sciencedirect.com/science/article/pii/S014976341...](https://www.sciencedirect.com/science/article/pii/S014976341000148X) [2] [https://www.ncbi.nlm.nih.gov/pubmed/7836619](https://www.ncbi.nlm.nih.gov/pubmed/7836619)

<comment> 52-6F-62 This subject seems to come up on this forum periodically. I'm really surprised how many people so frequently decide to treat the subject with such skepticism.

[https://www.ars.usda.gov/plains- area/gfnd/gfhnrc/docs/news-2...](https://www.ars.usda.gov/plains- area/gfnd/gfhnrc/docs/news-2013/dark-green-leafy-vegetables/)

[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1633749/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1633749/)

[https://www.nhs.uk/news/food-and-diet/eating-leafy-greens- ma...](https://www.nhs.uk/news/food-and-diet/eating-leafy-greens-may-help- prevent-memory-loss/)

[https://www.health.harvard.edu/vision/harvard-researchers- fi...](https://www.health.harvard.edu/vision/harvard-researchers-fight- glaucoma-with-leafy-green-vegetables)

[http://pubmedcentralcanada.ca/pmcc/articles/PMC5642804/](http://pubmedcentralcanada.ca/pmcc/articles/PMC5642804/)

[https://www.sciencedaily.com/releases/2017/07/170725122004.h...](https://www.sciencedaily.com/releases/2017/07/170725122004.htm)

Wash your greens well and make sure you eat them!

</comment></comment></comment><comment><USER6> Good thing they put some pesticide on it that makes me unable to eat these in USA....

<comment><USER7> So eat organic.

<comment><USER8> Or just wash your food.</comment></comment></comment>


Things We Learned Building a Complex React App - <AUTHOR> https://www.madetech.com/news/things-we-learned-building-a-complex-react-app <comment><USER2> Correct URL: [https://www.madetech.com/blog/things-we-learned-building- a-c...](https://www.madetech.com/blog/things-we-learned-building-a-complex- react-app)</comment>


Tesla Announces $1.6 Billion Convertible Notes Offering - <AUTHOR> http://www.teslamotors.com/about/press/releases/tesla-announces-16-billion-convertible-notes-offering <comment><USER2> Is there a reason for Tesla to raise funds via Convertible Notes vs issuing additional stock? I know little about this area.

edit: Thanks for a range of informative replies!

<comment><USER3> Cheap debt with enough financial engineering to minimize EPS dilution.

TSLA is an ideal stock for convert debt because it's highly volatile (compared to some other companies) which makes the pricing more attractive and opens it up for a certain class of buyers.

Source - I used to price these for a living.

<comment><USER4> These also allow for deductions at Tesla's applicable plain vanilla debt rate, which would be much higher than the cash interest rate on the notes (by using a call spread on top of the embedded option). So there's a tax arbitrage as well.

Source: I used to structure and sell these for a living

"In connection with the offering of the notes, Tesla intends to enter into convertible note hedge transactions and warrant transactions, which are generally expected to prevent dilution up to approximately 100% over the common stock price at the time of pricing of the notes due 2019 and 120% over the common stock price at the time of pricing of the notes due 2021. Tesla intends to use a portion of the proceeds from the offering to pay the net cost of the convertible note hedge transactions. In connection with establishing their initial hedge of the convertible note hedge and warrant transactions, the hedge counterparties or their affiliates expect to enter into various derivative transactions with respect to our common stock concurrently with or shortly after the pricing of the notes, including with certain investors in the notes."

<comment><USER3> Billy... it's David Cheng (Hans' buddy). BofA tech ECM desk, FTW.

<comment><USER4> Ha, amazing. FTW for sure! Hope you're well.

<comment><USER5> I always wish stuff like this happened to me on the internet.

<comment><USER3> Lawrence! You're exactly the same as I remember.

Get it?

<comment><USER5> Oh, I get it. I get it a lot.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Wow, they expect to be selling _half a million_ vehicles/year in six years. That would make make a Tesla a _major_ automaker, roughly in the same league as household-name auto brands -- you know, the ones that advertise in the Super Bowl.

<comment><USER7>
        Wow, they expect to be selling half a million
        vehicles/year in six years.

No no no, they expect to sell batteries to power half a million vehicles per year.. They intend to supply other auto companies with battery packs.

        That would make make a Tesla a major automaker,
        roughly in the same league as household-name auto brands.

It would still be a magnitude smaller than all 'major' manufacturers. Toyota sells ~10M/year, GM ~9.5M/year, VW ~9.2M/year, Ford ~5.5M/year, Chrysler ~2.4M/year, BMW ~2M/year..

There's no shame in being a wildly profitable smaller manufacturer though.

<comment><USER6> Ah, that would make more sense.

That said, half a million vehicles would make them 1/4th the size of BMW and 1/5th the size of Chrysler. For me, that's "roughly in the same league as household-name auto brands."

(For reference, right now, they are around 1/100th the size of BMW and Chrysler.)

<comment><USER8> 500k/year would put them in the same ballpark as the American subsidiarity of Hyundai (Hyundai Motor America) which made 720,783 cars in 2013 ([http://www.hyundainews.com/us/en- us/Corporate/SalesReleases/...](http://www.hyundainews.com/us/en- us/Corporate/SalesReleases/PressReleases.aspx)).

Obviously less than Hyundai internationally, but that might be an easier example to wrap your mind around.

</comment></comment></comment></comment><comment><USER9> This means that the law banning Tesla sales in Texas will be off the books in about 20 seconds.

<comment><USER10> If Texas is the right place for it, then so be it. But, it would be a great way to stick it to them by not choosing them because of their stance on traditional dealers vs. Tesla.

<comment><USER11> it would be sweet if Telsa uses this as leverage to roll back the dealership law.

<comment><USER12> That would be sweet but I can't see that dealership law standing indefinitely either way. I don't think Texas should get the plant unless they are truly the best place for it.

</comment></comment></comment></comment><comment><USER13> TSLA up 2% on the news:

[https://www.google.com/finance?cid=12607212](https://www.google.com/finance?cid=12607212)

</comment><comment><USER14> Usually, when you start investing in manufacturing, that means R&D has achieved all it could.

So is this factory a sign that Tesla is settling down on the current levels of cell capacity, charging times, weight, etc?

I.e. they don't believe in a breakthrough before 2020, do they?

<comment><USER15> I've never heard that view before. Do you know of some examples that fit that model?

The one I can think of that doesn't fit is Intel. They continue to innovate while investing in manufacturing.

<comment><USER14> It's not the fact they invest in manufacturing, it's the size of the investment compared to company size/assets.

Factory is supposed to pay for itself _before_ its product becomes deprecated. Looking at how expensive this gigafactory is - how many years will it take before profits from selling li-ion batteries cover the equipment & construction costs?

Some projections say peak output is expected by 2019-2021. Doesn't this imply that today's technology will still be competitive and in demand 6-7 years from now?

I'm assuming gigafactory uses chemicals and tech that powers current generation of Tesla cars. Because if they had something significantly better they would not care about 2019, but would instead die to get it to market ASAP. Not caring about unit price or volumes. Just to prove that it works and to capture the high end market.

And my second assumption is they don't plan to lose money on this project.

<comment><USER15> > Some projections say peak output is expected by 2019-2021. Doesn't this > imply that today's technology will still be competitive and in demand 6-7 > years from now?

Tesla never said they will be building today's batteries in the plant and I would be surprised if your assumption is correct. They likely have projections on their R&D and can also project how long it takes to build massive capacity on what they are building.

All major manufacturers of all complex products are faced with the same challenges. Management must match R&D to production or they will have huge misses. Manufacturing true technologically advance products is tough.

There are many examples of companies that simultaneously invest in R&D while making far out production capacity investments: Intel, all Pharmaceutical companies etc. etc.

If you can think of some companies that invest heavily in R&D, then stop investing in R&D and start investing in manufacturing, I would be interested in learning about them and why.

<comment><USER14> I don't know how Intel operates. Did they start building a 90nm factory before they finalised the process of making a 90nm chip? Can they upgrade a 90nm plant to start producing 45nm, and will it cost less than half of the original spend?

As for pharmaceuticals - I'd expect their plants to a) be capable of producing multiple different compounds and b) equipment to be modular. Research & clinical trials are expensive, reconfiguring equipment to make newly discovered drug is cheap. Once proven to work, drug can be replicated fairly quickly and cheaply, that's why they push so hard against any patent law reform.

</comment></comment></comment></comment></comment><comment><USER16> A half-million batteries a year means they need raw materials to support that production. Are there suppliers that can do that? After all, these are car- sized batteries, not phone-sized ones.

</comment><comment><USER17> Fuck, I read all that and still no news of a Tesla Convertible. Bring back the Roaster! Any executive that opts to discontinue a 2-seater needs to be shot.

<comment> josh-wrale I wouldn't be surprised if the reason for a current lack of a convertible is a strategic move away from the following things:

1) making the cars even more expensive (by making) 2) things that have to high potential for fatality 3) things that require lots of engineering, testing and certification for a limited appeal/run (and thus limited profit)

It will be awhile on that convertible, I bet.

The Model X has gullwing(-like) doors.. That's pretty cool, right?

<comment><USER18> > _The Model X has gullwing(-like) doors.. That 's pretty cool, right?_

[http://i52.photobucket.com/albums/g24/speed_addict/Lambo- Doo...](http://i52.photobucket.com/albums/g24/speed_addict/Lambo-Doors-So- Played-Out.jpg)

<comment> josh-wrale That is a truly awesome image. Here's the Model X: [http://image.automobilemag.com/f/57687390+q100+re0/Tesla- Mod...](http://image.automobilemag.com/f/57687390+q100+re0/Tesla-Model-X- falcon-doors.jpg)

<comment><USER8> Does anybody know if those doors have cup-holders? Parents of small children might get a little surprise when they open up those doors if they do.

In any event, they seem more practical than regular doors and are certainly cooler than sliding doors.

<comment><USER19> That must have been a design tradeoff.

These are some pictures of the Model X, I have found. There are no "holes", only arm-rests. The black detail on the second picture must be the window control.

[http://d.ibtimes.co.uk/en/full/230436/model-x.jpg](http://d.ibtimes.co.uk/en/full/230436/model-x.jpg)

[http://b.fastcompany.net/multisite_files/codesign/poster/201...](http://b.fastcompany.net/multisite_files/codesign/poster/2013/01/1671665-poster- tesla-model-x.jpg)

</comment></comment></comment></comment></comment></comment><comment><USER20> Vertically integrating seems logical. Next step, lithium mines?

And will they build the same 18650 packs, or develop something new?

</comment><comment><USER21> Just curious, how does this differ with 'junk bonds'?

<comment><USER11> 'junk bonds' are bonds with a high interest rate because of poor credit quality.

convertible bonds basically have an equity option attached, so the interest rate paid by the issue is lower than what it would be otherwise (because the buyer is getting an option).

Often it is low grade companies that issue convertible bonds (to keep the interest expense they pay down), but it doesn't have to be. Investment grade companies can issue converts as well.

</comment></comment><comment><USER22> Buying more panasonic stock as we speak. They are one of their main partners and the stock is still damn cheap.

</comment><comment><USER23> Oh, the Tesla website is available in French now and they're building stores all over Europe.

</comment><comment><USER24> So, bet's that the recent Apple/Tesla meetings were about Apple joining this?

<comment><USER25> those meetings with Apple weren't really "recent". But yeah Apple has a high interest in batteries as well of course.</comment></comment>


App Store Bit Rot - <AUTHOR> http://www.undsoversum.de/2012/09/18/app-store-bit-rot/

<comment><USER2> I doubt this will ever be fixed by Apple because this issue affects so few people. The overwhelming majority of iOS devices in active use can run at least iOS 4.3[1], and I'd guess that the users that don't upgrade to the latest iOS version are the same ones that don't update all their apps through iTunes. I'm guessing that the number of users who update their apps through iTunes but don't update their device (or can't update their device) to the latest iOS is very small.

I wasn't particularly thrilled that I was forced to drop support for iOS 3, but looking at the number of active users of my app[2] that were running the current version, I saw that _none_ of them were on iOS 3. This was probably the right time for Apple to drop support for < iOS 4.3.

[1] I don't have stats to back this up, but seeing that iPhone 3GS is the lowest hardware to support iOS 4.3, and they've sold way more devices since then than original iPhone and iPhone 3G, I think it's fair to assume that the vast majority of iOS devices in use can run iOS 4.3 or later.

[2] <https://ironmoney.com/ios/>

<comment><USER3> While [1] may be true, many people never upgrade their iOS.

My stats are such that 8% of my users are using < iOS 4.3, and of that 8% slice almost 3/4 (or 6% of my total users) _could_ update to something newer, but they're happily running old iOSes.

If I were to cut them off, would that magically make them upgrade? I don't think so. They'd just be bummed that their apps stopped working.

<comment><USER2> I don't think that would magically make them upgrade either, although they might be willing to do so since the only thing we can do is not upgrade our apps to support them.

Obviously this will vary from app to app, but I'm surprised that you have such a high number of users with an older version of iOS. Is that across all of your apps/games?

<comment><USER4> I can collaborate that data somewhat - across the US apps I have access to stats for (a sizeable number of users) I see a similar figure (~6.5%) running iOS 4.3 and lower.

However, only 0.7% of _devices_ are iPhone 3G and lower, so the majority of users I see running <4.3 are not updating out of choice.

This is all anecdotal, though - figures will vary dramatically across apps/demographics/etc.

</comment></comment></comment></comment><comment><USER5> The idea that Xcode 4.5 is required for iPhone 5 development is incorrect. If iOS3-4 & ARM6 support is needed, Xcode 4.4 could be used (at least for now) to build iOS3-5 apps. The trigger to make an app use full iPhone5 screen is to include firstname.lastname@example.com into the project. Of course, you'll need to modify screens to adjust layout depending on screen size.

Having said that, Apple typically pushes everyone to upgrade to the latest Xcode, and OS/X, so I'd expect that Xcode 4.5 will be required rather sooner than later. IMHO, this is a good thing in the long run, better than supporting multiple generations of hardware and software - it's better for the ecosystem. Even though about 8% of our users are on <iOS4.3, we would be fine when Apple drops them - they would provide us more users on iOS6+.

<comment><USER6> > The trigger to make an app use full iPhone5 screen is to include > firstname.lastname@example.com into the project.

Have you tested that without using the new SDK, or is that a theory? The email@example.com might be required-but-not-sufficient.

<comment><USER5> Yes, it's been confirmed to be sufficient.

As an additional evidence, one of our apps that included this file received "required screenshot is missing" iTunes Connect status upon update upload today, and it had all regular screenshots, but not iPhone5 ones.

<comment><USER7> Do you know how to run Xcode 4.4-compiled binary in Xcode 4.5's iPhone simulator?

<comment><USER7> Okay, I was able to confirm sergeo's statement. Here's what I did:

1.) I compiled my app with a 4-inch default image using XCode 4.4.1 with iOS 5.1 as the base SDK and ran the app in Xcode 4.4.1's iOS simulator.

2.) I copied the resulting i386 app folder from /Library/Application Support/iPhone Simulator/5.1/Applications/[app uuid] to /Library/Application Support/iPhone Simulator/6.0/Applications/

3.) I started XCode 4.5's iOS Simulator and ran my app from Spring Board.

The result? It did work. I was able to see my Xcode 4.4.1-compiled app in 4-inch display mode.

I can't say for sure if this will work on the iPhone 5 hardware, but I'd bet the answer is yes.

I guess with this finding, if you're not using any iOS 6.0 features, it may be better to continue to compile your app using Xcode 4.4.1 since that lets you more easily produce app with armv6 support.

</comment></comment></comment></comment></comment><comment><USER8> This isn't Apple's style. Apple has planned obsolescence.

The other thing is that there has been over the air upgrades since iOS 5, so people _do_ upgrade their iOS version.

From my multiple app stats (thousands of users), less than 2 percent run iOS < 4.3.

98% run iOS 5 or higher.

<comment><USER9> Also note that the iPhone4 is now offered for free with most upgrade plans. If you have a 3G still kicking around on a regular plan, the upgrade path to (at least) the 4 isn't painful.

<comment><USER10> It's not free per-se. It requires a 2-year commitment (3 years here in Canada). Agreeing to a 2-year commitment to get a 2-year-old phone is probably a bad deal (especially given Apple's lack of support for the less-than-4-year- old iPhone 3G). I don't expect a high percentage of people to go for that one.

<comment><USER11> If they were planning to have a cell phone for the next two years _anyway_ , then it makes little difference. The commitment reduces their choices, but if they weren't planning to change then it doesn't much matter.

<comment><USER12> If they were planning to stay with their current provider on their current plan, perhaps.

Off-contract: Customer: "I'm thinking of switching to provider B as my bills are high." Provider: "I'm sorry to hear that, can I knock $15 off your bill?"

On contract: Customer: "I'm thinking of switching to provider B as my bills are high." Provider: "Certainly, that'll be $200." (Or your remaining ETF amount.)

But hey... free phone!

</comment></comment></comment></comment></comment><comment><USER13> At this point, I have <2% users on something < iOS 4.3. I have 0 users < iOS 4.0. There are a few users out there I'm sure, but it's so small of a number as to not be worth supporting as either Apple or as an app developer. 95+% are on 5.0 or better, and I'd be willing to bet >80% will be on iOS 6 in the next month. Supporting iOS 3 at this point is silly.

</comment><comment><USER14> I've considered using source control on my IPAs just in case I want to roll- back an app. It's happened a few times, like when developers break compatibility, or when they introduce ads and/or IAP, or sometimes I just don't like an update.

<comment><USER15> I _ONLY_ update programs through iTunes. When it sticks the old version in my trash, I grab the ipa and put it into my "backups" directory.

I've known way too many people who have been burned by things like "ugh, this version doesn't work on my phone, but I have no way to get the previous version!"

Also, there are cases where a feature is removed from the new version, thus making it useless. My system helps fight against that.

<comment><USER16> That's exactly the method I use as well. There's one app that I use that an old update adds advertising, and breaks most of the functionality. Based on the reviews, further updates do nothing to improve the broken bits, and made the advertising even more intrusive.

I see no need to update a perfectly functional piece of free software and turn into a crippled piece of ad-delivery-software.

If I get careless and hit the "update all" button, or get click-happy in the list of updates, the old version ends up in the trash can. If I still don't catch it and dump the trash, I can still go back because I've got the old ipa sitting in my "Old IOS Apps" directory.

<comment><USER15> Sounds like Angry Birds.

There was one game that I had (Clickomania HD?) that went from a full version that cost money to a free version with 3/4 of the functions removed and ads added in one update. It's been sitting in the "hey, update available!" section of my iTunes for close to two years.

<comment><USER16> A unit conversions utility that has a very nice, clean UI with a focus on functionality, not on "what trendy widget can we force in there next?"

Well, had, anyway.

</comment></comment></comment></comment></comment><comment><USER17> As much as I agree that Apple should keep support, I am not upset they're not keeping support for a phone from 2007. We live in an age where most people replace there phone every 1-2 years. 3 at a very big stretch.

While you may not replace your phone that often, a very large majority do.

<comment><USER18> > I am not upset they're not keeping support for a phone from 2007.

Except that sales of the iPhone 3G seized... on June 4th, 2010. Of the iPod Touch 2G, with the same CPU, on September 1st, 2010.

This isn't about not keeping support, this is a bit more fundamental. This is about no longer being able to get things onto devices that were sold barely two years ago any longer. And possibly not even being able to compile things for those devices.

Two years. That's the lifespan Apple gives your devices. Two years and a few weeks and it's obsolete.

The iPad 1 was introduced on April 3rd, 2010. And that was the Wi-Fi version, in the US only. The last update for the OS it'll ever get was released on May 7th, 2012.

Two years, plus a few weeks, and it's obsolete.

Two years is how long Apple plans for your device to last before they want you to buy a new one.

\----

In fact, if you bought a brand new iPod touch 2G from Apple, on September 1st, 2010, you got your last OS update on November 22nd 2010. That's less than three months. And people say that Android doesn't support its devices with updates...

<comment><USER19> While i agree that (planned) obsolescence is a bad thing, Apple/iOS is still in a way better shape than Android where some devices never ran a current-gen version of the OS and never saw an update to a new major version.

[http://theunderstatement.com/post/11982112928/android- orphan...](http://theunderstatement.com/post/11982112928/android-orphans- visualizing-a-sad-history-of-support)

<comment><USER18> That chart is seriously wrong.

For starters, not least of all due to the definition of "major version".

And also because being stuck on one Android version is not so bad since apps from the Android Market have way more control over the OS than Apple's. If the built-in WebKit is a security risk, you can download Firefox or Opera or a browser that comes with its own WebKit or whatnot, and will be able to do so forever. You can sideload it, if you're so inclined. On an iPhone 3GS, you'll be stuck with that version of WebKit forever.

And ever.

Until Apple shuts down their authentication servers (or 404s/times out a certain URL on their servers for that model of phone) for that phone and what you'll have then is a brick.

Your iPhone will last as long as Apple chooses. And if Apple doesn't choose, they're gone and it's a brick. Either way, Apple got your money.

</comment></comment></comment></comment><comment><USER20> My iPhone 3GS is dying, I bet there are a lot of iPhone 3G customers that are either changing phone because their beloved iPhone does not work anymore or are using their iPhone so lightly that the only application they use is Safari (no apps installed). So I guess there will be no problem at all or the problem will affect a tiny portion of the % of people that have an iPhone 3G that it will just not matter at all.

</comment><comment><USER21> Apple is not just in the business of selling iPhone, its in the business of selling New iPhone to old customers. It makes sense to keep reminding your old customers that "hey you got old phone, you need to upgrade your hardware to use this new awesome app".

</comment><comment><USER22> The last time I restored an iCloud backup, it actually redownloaded older versions of the apps (specifically, the versions I had installed when I made the backup). So I think the answer is "use iCloud backups".

<comment><USER23> iOS 4.x doesn't have iCloud.

<comment><USER22> Huh, guess it's been a while since I used that. Oh well.

</comment></comment></comment><comment><USER24> When developing anything for any platform as developers we all make a conscious decision about our cutoff points. Do we attempt to support as low as we can go? Do we get progressive? They're all tradeoffs that we have to make, and have to decide on.

Apple might not be making it easy to stick with a low as we can go but it's still doable, so I'd guess the developers have made the decision and taken the tradeoffs.

</comment><comment><USER25> Apple does not support devices older than 24 months. It has always been this way. I say this because we've seen this pattern with older iPhones and iPod Touches losing features and functionality since the very beginning.

For example, I was very disappointed when Apple made changes to iOS 2 so that the original iPod Touch couldn't change it's volume. The newer iPhones and iPod's had hardware volume controls so iOS removed the easy volume adjustments from the software. The iTunes app could still adjust volume and that must've been good enough, because I didn't see many people complaining.

The customer experience matters a lot to Apple, and they are awesome at it. However, I agree with that article and I would love if they started also maintaining the experience of their older existing customers.

</comment><comment><USER26> Also no way to stop an app from appearing in the update list even if you consider the latest update a downgrade</comment>


C++17 – The Complete Guide - <AUTHOR> https://leanpub.com/cpp17 <comment><USER2> This page appears to be a product advertisement, not a resource in of itself.

<comment><USER3> Also the complete guide is ironically only 70% complete.</comment></comment>


MacOSX will take 15 years to surpass Windows at current growth rates - <AUTHOR> http://successfulsoftware.net/2009/01/09/macosx-market-share/

<comment><USER2> Assuming current growth rates will not change over 15 years for any technology makes you into an ass.

<comment><AUTHOR> From the article: "Of course, it is highly questionable to project 15 years from a single year of data"

<comment><USER2> Good point, but the headline is linkbait.

<comment><AUTHOR> You were expecting something else on a social news site? ;0)

</comment></comment></comment></comment><comment><USER3> So? Does Mac OS X need to surpass Windows to be successful?

Seeing as Apple has more cash on hand than Google or Microsoft, (or both, combined) I'm guessing no.

(Just another question: How many years will it take the Zune to the surpass the iPod at current growth rates?)

<comment><AUTHOR> >Seeing as Apple has more cash on hand than Google or Microsoft

Really? Got a source to back that up?

<comment><USER4> Try yahoo finance. Cash on hand as of end of fiscal year:

* AAPL 24.49B (on 27-Sep)

* GOOG 14.41B (on 31-Dec)

* MSFT 19.71B (on 30-Sep)

<comment><AUTHOR> It isn't as much as both combined. But that is an impressive mountain of cash. Does Steve Jobs give anything to charity, or does he just spend all sledging down his pile of money?

<comment><USER3> It actually IS more than both Google and Microsoft combined. They're required to break up the revenue from the iPhone over 8 quarters -- its supposed to be spread out over the life of the iPhone's subscription. But its all paid to Apple upfront.

While that listing didn't show you exactly how much earnings was reported that quarter from Apple, but its fast becoming their bread and butter. And yes, if you end up multiplying that value by 8, Apple's cash on hand last quarter was something like $40 billion.

(Still looking for a URL to back up my sources. DaringFireball.net did an analysis where he was quick to point this out. I think the closest I can find to the number crunching was this: <http://daringfireball.net/2008/10/the_phone_company> )

I remember the post addressing re: iPod Touches and charging for updates -- because they're not part of a subscription, but yeah, either way, there's a lot of evidence that the "cash on hand" is significantly larger than what's being reported, due to accounting reasons.

</comment></comment></comment></comment></comment><comment><USER5> I'm not a statistician, but assuming growth continues, once it hits a certain threshold (a tipping point) the rate of growth will accelerate substantially.

This means that if OS X is ever to surpass Windows, it will probably happen in a lot fewer than 15 years.

</comment><comment><USER6> So I guess in 2007 he could have claimed that Apple would take, uh, \lim_{x -> pi/2^(-)} \tan(x) years to surpass Palm's market share? (please excuse the bastardized TeX, but \frac is too verbose for ASCII)

</comment><comment><USER7> The Mac's market share is growing simply because market share doesn't matter anymore. Thanks to the Internet, people are buying the computers they want, not the one they feel constrained to buy.</comment>


Dtube – A decentralized video platform using STEEM and IPFS - <AUTHOR> https://d.tube/ <comment><USER3> Ok, so I'm looking at a website that tells me it's decentralized.

But from all I can tell this is just a good old website. Somebody has control over the domain name. Points it to servers of his choice. And the servers deliver content of his choice. What's decentralized about it?

<comment><USER4> A good old website? No.

We don't need the domain, you can take the [https://github.com/dtube/production](https://github.com/dtube/production) repository, ipfs add -r it on ipfs, and use DTube this way -> [https://ipfs.io/ipfs/QmRWPnY8h7Eg4v74GtKT6UBy2kUAN139QwYPUrg...](https://ipfs.io/ipfs/QmRWPnY8h7Eg4v74GtKT6UBy2kUAN139QwYPUrgRUiDPMe/#!/ipfs/QmRWPnY8h7Eg4v74GtKT6UBy2kUAN139QwYPUrgRUiDPMe/) (few bugs but it works apart from /home not being rendered on first load, you need to click the logo)

What is decentralised:

\- The website (its fully static and can be hosted on ipfs)

\- The video storage (IPFS)

\- The account system / commenting / voting / subscribing (when you do that, it directly creates the transaction on the blockchain)

What isnt decentralised:

\- The upload endpoints (upldr*.d.tube). You can legitimately avoid it if you have a local IPFS node running and you add files yourself, however it's really not convenient for users.

\- The search endpoint (asksteem.com). This is used for the search, tags browsing, and related videos.

\- Server side rendering stuff for robots only (we enabled that recently)

P.S: I am the founder of DTube

<comment><USER5> ipfs.io it's part of a centralised DNS system(.io cctld) so when ipfs.io goes down I assume your website will go down as well?

<comment><USER6> run a local ipfs node and replace the ipfs.io part with your IP, it will work fine.

you can even mount ipfs as a readonly filesystem and cat that hash and get the content.

<comment><USER7> If you install ipfs-companion browser extension, it will automatically turn all ipfs.io/ipfs/ links to links to your locally running gateway.

<comment><USER8> It actually replaces all links of the form /ipfs/<valid hash> , regardless of the domain.

</comment></comment></comment></comment></comment></comment><comment><USER9> Steem looked like an interesting idea, but your content lives and dies with the platform's whales, which are either insiders or a few people who believe in the platform. If the whales don't interact with your content, you're not likely to get much revenue. You voting power -- the amount you contribute to content you interact with -- is directly tied to your steem power, so unless you put money into the platform or managed to make money and kept it in the platform, you're not going to contribute much.

Similarly, as a user, contributing upvotes, comments, etc. nets you a curation reward, but this comes in trickles mostly unless you lease your steem power to vote bots.

Also worth noting that the whole steem platform on the currency end of things is completely centralized, so if that matters to you, this is important to know.

<comment><USER10> > Also worth noting that the whole steem platform on the currency end of > things is completely centralized

This is a central Youtube-like clone it seems. I can't scale in bandwidth and has a central governance model.

Plus the coin is worthless: "The number of Steem available is set to double annually, making its supply growth exponential - a possible drag on its future value in the market" [https://www.investopedia.com/news/steemit-disruptive- blockch...](https://www.investopedia.com/news/steemit-disruptive- blockchainbased-media-community/)

"IPFS is cool, but there is no magic. Someone needs to seed the files, and your browser cannot permanently store huge files (local storage is limited to 50MB on most browsers), so seeding through the app directly is not possible as of today. " ([https://steemit.com/video/@heimindanger/introducing- dtube-a-...](https://steemit.com/video/@heimindanger/introducing-dtube-a- decentralized-video-platform-using-steem-and-ipfs) thnx ForkLDing).

Disclaimer: working for 13 years on an academically-pure Bittorrent-based decentralised solution with my university lab.

<comment><USER11> In this instance, heavy inflation might actually be a plus for STEEM. This is because it doesn't appear to be intended as a store of value, but as an influence market.

As far as I can tell - and I'm sure there's a lot I've misunderstood - <USER2> is essentially a market for on-line influence. You gain STEEM for upvotes etc. and the more STEEM tokens you have (STEEM Power), the more influence you have in terms of who gets STEEM tokens.

Now, this sounds kind of pyramid-y to begin with, but without significant inflation, such a system would seem doomed to form an oligopoly of a few users who, by virtue of their "STEEM Power" would gain an ever-increasing share of the tokens minted, pushing everyone else out and probably killing the whole ecosystem. Of course, that may still happen even with inflation.

<comment><USER10> > Now, this sounds kind of pyramid-y

Unlimited money creation is never sustainable, history shows. An online attention coin can't change economics. The future of television probably is not build on a high inflation economy or destructive hyperinflation. [https://scholar.google.com/scholar?q=high+inflation+~economy](https://scholar.google.com/scholar?q=high+inflation+~economy)

<comment><USER12> It sounds like they're not trying to create general-purpose money. They've made a token to track influence. They use inflation so old stored influence loses half its value every year. You can't rest on your laurels, if you want influence you have to have provided value recently.

<comment><USER13> You are completely wrong, and the above people, about steem doubling every year for the total amount, it only increases by something like less than 10% per year.You or someone above you linked an article from 2016 that has very outdated information.

I figured people here might actually do any amount of research instead of just saying vague statements like "resting on your laurels". You have no idea what you are commenting on because it is 2 year old information, but you are acting like an expert. Pathetic.

</comment></comment></comment></comment></comment></comment><comment><USER14> Also checkout peertube which is also federated but doesn't run on IPFS: [https://github.com/Chocobozzz/PeerTube](https://github.com/Chocobozzz/PeerTube)

<comment><USER15> Another one is bitchute.com

<comment><USER16> For the lazy: [https://bitchute.com/](https://bitchute.com/)

</comment></comment></comment><comment><USER17> Can there be a general explanation for what all the things including the cash symbols mean and how all the videos sourced from (like using IPFS) if its not too privately protected?

Much thanks!

EDIT: Nevermind, found it, link below:

[https://steemit.com/video/@heimindanger/introducing- dtube-a-...](https://steemit.com/video/@heimindanger/introducing-dtube-a- decentralized-video-platform-using-steem-and-ipfs)

<comment><USER18> Thanks for the link

</comment></comment><comment><USER11> So where does the money come from? This might be a question about STEEM more than DTube, but I couldn't figure it out.

The DTube FAQ answer for "Where does the money come from" just says "The STEEM blockchain keeps printing new STEEM everyday. These new printed STEEM are given out as rewards." I'm hoping there's more to it than that, but I couldn't find what the mechanism for bringing value into the STEEM ecosystem is.

As far as I can tell, users of DTube don't pay anything to watch videos, or to comment, or to like videos, but their likes determine who gets paid on the STEEM blockchain. So who buys STEEM tokens and why?

<comment><USER19> edit: [https://steemit.com/faq.html#How_does_Steemit_work](https://steemit.com/faq.html#How_does_Steemit_work) might be better.

"Every day, the Steem blockchain mints new STEEM tokens and adds them to a community's "rewards pool". These tokens are then awarded to users for their contributions, based on the votes that their content receives. Users who hold more tokens in their account as "Steem Power" will get to decide where a larger portion of the rewards pool is distributed."

</comment></comment><comment><USER20> Interesting idea, but unfortunately (and as expected) full of antisemitic and "new world order" conspiracy stuff by people that claim YouTube is censoring them.

<comment><USER21> Why is this a bad thing, let people post what they want to. Also if someone says YouTube is censoring them why wouldn't you believe it?

<comment><USER22> It's likely to forever remain a niche for that kind of content only. What reasonable person would say: "I know, I'll host my video on that website which opens with a list of conspiracy videos and has antisemitism promoted in the sidebar next to my content/face." (And even more - which popular company would do that?)

<comment><USER8> If there are enough benefits to the platform and semi-popular (likeable) Youtubers switch to it, the problem should resolve itself after a few days. Luckily antisemites etc. are a minority of the population and can be easily outnumbered.

<comment><USER23> That's a really big IF, and semi-popular Youtubers have even more to lose from association with the existing content on there than most of us.

<comment><USER8> I think the question is if the risk of very loose association with that content is higher than the risk of loosing out on revenue by arbitrary decisions from Youtube.

Given what happend over the last year with the Adpocalypse, most of them realized that being at the whim of Youtube is a real risk, and are now looking to diverisfy their income streams (see growth of Patreon).

</comment></comment></comment></comment></comment></comment><comment><USER24> How does it compare to Peertube? [https://peertube.cpy.re/](https://peertube.cpy.re/)

Ah I see, DTube is based upon IPFS, while peertube relies upon good ol' BitTorrent directly (though IPFS uses BitTorrent too?)

<comment><USER25> ipfs is a new protocol which happens to do similar things to bittorrent. For simplicity you can think of it as bittorrent with folders

</comment></comment><comment><USER26> If you're not familiar with STEEM or its currency, you can check the FAQ. [1]

[1] [https://steemit.com/faq.html#What_is_the_difference_between_...](https://steemit.com/faq.html#What_is_the_difference_between_STEEM__STEEM_Power__and_Steem_Dollars)

</comment><comment><USER27> It rubs me wrong that anonyhack is reposting videos from YouTube and claiming credit for them, in cryptocurrency and STEEM:

[https://d.tube/#!/v/anonyhack/3w9xsp8j](https://d.tube/#!/v/anonyhack/3w9xsp8j)

[https://www.youtube.com/watch?v=XEBWtbhq0Ts](https://www.youtube.com/watch?v=XEBWtbhq0Ts)

Can anything be done to prevent or deter this?

Other than maybe leaving comments on the page?

</comment><comment><USER28> It amazes me how skilled we are in pointing out what is wrong with something.

<comment><USER29> Well right things need no fixing, so pointing out wrong things is more useful.

</comment></comment><comment><USER30> [https://about.d.tube/](https://about.d.tube/) \- A landing page presenting and explaining DTube

[https://github.com/dtube](https://github.com/dtube)

</comment><comment><USER31> So this is pretty amazing. But how in the world are they going to survive the obvious issues such as copyright violations?

<comment><USER32> Isn't that the point behind this? It can't be censored. You don't do anything, because you can't do anything.

</comment></comment><comment><USER33> Cool project! But I have a hard time shaking the feeling that a lot of the content and comments are bots or are paid for.

<comment><USER34> Most new social networks suffer from this issue early on, the only solution is mass adoption and curation which the STEEM seems to be working toward.

</comment></comment><comment><USER35> I like the idea and would love to try it! I have one small concern though. Since the incentive (money) is given to popular videos, why people should post unpopular opinions in Stemmit or videos in Dtube?

That is, if I upload a video of a cat doing some funny thing I'll get more tokens (potentially) that with a super technical video.

<comment><USER23> Having a platform that incentivizes popular content should in theory attract popular content to the platform. This should attract viewers to the platform, thus increasing the viewership available to see your less popular content.

Meanwhile, incentivizing popular stuff doesn't take anything away from you or your content. You're not being penalised, so why complain?

<comment><USER35> > Having a platform that incentivizes popular content should in theory attract > popular content to the platform. This should attract viewers to the > platform, thus increasing the viewership available to see your less popular > content.

Thanks for pointing that! I didn't though of it this way. To be honest, my fear is that this platform could turn possibly in some sort of niche. Right now, popular content is about X, so if I want to make quick profits, I'll create a video about X. More people will join and do the same.

I'm sure there are ways to fix that like giving people incentives for posting in unpopular topics. Potentially, each topic could be its own market!

> You're not being penalised, so why complain?

Not complaining at all for now. Just sharing my current thoughts! If I join a social media, I'd love to have diversity of content and opinion. I think in STEEM that could be hard, as it is in Reddit unless you subscribe to unpopular ones. Not a 100% bad thing though!

</comment></comment></comment><comment><USER36> I've had a sense that something like this would be the future. However for the less up to par with cutting edge web technologies, how about a single page that in a condense manner describes the technology behind this? Even for a person somewhat up to date with distributed technologies it takes at least an hour to understand exactly what's going on.

Again not trying to be harsh, but I feel that the UI, in this stages looks a little bit too much like youtube, giving it a cheap feel, that makes it a bit hard to sell to "normal" people.

And oh, I feel that having three decimals on the earnings looks a bit weird to me. Isn't two decimals enough? Say $116.688 is hard for my brain to parse either it's 116 dollars and 68.8 cents or maybe it's around 1 million dollars???

</comment><comment><USER37> I wonder if IPFS can be connected to Cloudflare such that CF ends up acting like a CDN for IPFS network. The content is encrypted (so that the CF does not know what's being served) and users can offer their own Cloudflare API keys to take part in the network.

Edit: Please tell me why the downvotes.

<comment><USER38> You're likely being downvoted because IPFS is already effectively a decentralized CDN. By adding CloudFlare in the mix, you've just re-centralized it - in other words, you've defeated the entire purpose of the platform.

</comment></comment><comment> g-b-r [https://decentralize.today/the-ugly-truth-behind- steemit-1a5...](https://decentralize.today/the-ugly-truth-behind- steemit-1a525f5e156)

It's rather old (2016-08) but at a quick glance it appears to be correct and still relevant.

</comment><comment><USER39> How is abusive content handled on this platform?

<comment><USER16> Users can downvote.

</comment></comment><comment><USER40> What steps are being done to combat the doxing of individualists on DTube? DTube doesn't have much of a mainstream future if it becomes a haven for people harassing others / posting their personal information.

<comment><USER4> I believe the same applies to steemit.com. Well once something gets written on the blockchain, it's hard to remove it. The DTube domain (that we control) would always be able to block certain videos in extreme cases, but the videos would still be on IPFS.

And there isn't much we can do about that, it's the same case as when someone gets seeded on torrent. You can find the nodes seeding a particular content by doing ipfs dht findprovs <hash> , then you get their ips and you go after them legally.

</comment></comment><comment><USER41> Is it streaming from IPFS directly? Or is d.tube (website) hosting a mirror?

<comment><USER42> Looking in the "Network" tab in your favorite browser's developer tool, you can see that the videos are requested from the public IPFS gateways. Example: [https://ipfs.io/ipfs/QmSDWa2kc2vSpbVBvxswZqcUEFTVPBJQyZyjgjT...](https://ipfs.io/ipfs/QmSDWa2kc2vSpbVBvxswZqcUEFTVPBJQyZyjgjTUQVn1Ta)

Disclaimer: I work for Protocol Labs on IPFS

</comment></comment><comment><USER43> Wow, this is amazing. I think this is a YouTube killer for sure. I'm just waiting for my account to be accepted.

Just one request. I love the YouTube JKL control keys. Any chance you could implement this on D-Tube?

</comment><comment><USER44> I don't think scrolling on the video to change the volume is a good idea. I jumped because the volume of the video suddenly changed as I was trying to get around.

</comment><comment><USER45> Would this not run into the copyright issues most other distributed hosting networks run into? Especially since it allows directly monetizing the content.

<comment><USER46> Copyright issues are the easy end of the problem stick too. I'm going to straight up ask - what happens when a child porn ring starts using this?

<comment> 52-6F-62 It appears to already be a home to some fringe stuff.

"Big cities are like financial slave camps - Take a break at the Zenvow Meditation Resort - All crypto Meditation Resort in Portugal" (of course this is crazy, but harmless—at least initially)

I would also like to know what solution has been proposed for that problem.

</comment></comment></comment><comment><USER47> Good stuff. I posted some technical videos about DTube/IPFS vs. HLS+CDN in the past few days (2x 20min), and design lectures in the past 90 or so days (2-3x50min)... I forget etiquitte about posting links but my profile has some pointers and I use this handle widely on the web. Highly recommend if DTube is of interest (unscripted+uncut, I rewatch them a few times for myself but share).

</comment><comment><USER48> I've been wondering for a long time, how do you remove illegal content. I don't care so much about copyright and minor offenses like that, but more serious offenses like child pornography. If there is no way to remove it, people and governments will start to take action against the whole website, decentralized or not.

</comment><comment><USER49> Just went through the html to figure out the js library that they used but instead found a lot of elements having the same id's in the page. Looks like the frontend was hastily written to make it just work.

</comment><comment><USER50> The cash amount by each video mean what?

<comment><USER51> thats what the users earned by getting liked by other users

<comment><USER52> cumulatively or is that how much they're earning per month?

<comment><USER53> It's how much they've earned for that particular video so far. I've been saying it for a while here but nobody seemed to listen. d.tube is way better for smaller creators than YouTube is right now, and with a tiny fraction of YouTube's audience.

Plus, YouTube is only going to get worse for small creators, as Google tries to cater more and more to the big companies and punish the creators for "advertiser-offensive content". Meanwhile, d.tube should get better and better as both it and STEEM (the tipping mechanism) rise in popularity.

The nice part is the creators don't even have to give-up YouTube to try out d.tube. They can just upload the video to both and see for themselves what's the difference.

<comment><USER54> With a new monetised platform, with money being incredibly obvious on the UI, the incentive is pretty high to just steal popular content from YouTube and repost it. How do they ensure original content or ownership?

<comment><USER55> If Facebook doesn't care about enforcing copyright, why should such a small website?

That really seems like an argument that is made only to hurt startups.

<comment><USER51> > That really seems like an argument that is made only to hurt startups.

you're looking at this the wrong way. Yes, startups should enforce copyright. But so should facebook.

They just get away with it because they are big

<comment><USER56> Yes, that's the point the commenter is making.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER57> please make making an account easier. not going to give a phone number. email is easier to bypass.

</comment><comment><USER58> This is really exciting and has a lot of potential.

The pause button is broken on Android Firefox, though. :)

</comment><comment><USER59> Wow, nice domain. I wonder how much that cost

<comment><USER4> Actually we started out with dtube.video domain and the .TUBE registry owner noticed and liked our project so much that he offered the domain for a very fair price. :))

True story

<comment><USER59> wow, very cool.

</comment></comment></comment><comment><USER60> This is real good work.</comment>