The idea is that you're not double taxed. If you're using a CDN already like Akamai for instance, you wouldn't pay Peer5 for the HTTP bytes. Only Akamai would charge you for that.

But why bill based on the bandwidth at all? Is it just a matter of being easy to understand and will equate to more than request based billing?

With a P2P network the bandwidth isn't being paid for anyway as you're using the end user's outbound connections. The tech behind it does sound interesting but it sounds more like a library than a metered service.

It's just a very standard and easy to understand model that people are familiar with. We may explore some other options in the future.

Hi, Hadar here, Co-founder and CEO of Peer5. PeerCDN started at about the same time as Peer5 and was a competitor. Later it was acquired by Yahoo.

PeerCDN was a general purpose CDN, while Peer5 specializes in video. Feross, one of PeerCDN's founders and author of WebTorrent actually became my friend and we exchange ideas from time to time.

My name is Hadar and I wrote this, let me know if you have any question

Hadar from Peer5 here. We'd be happy to share whitepapers and case studies about our p2p cdn. Feel free to contact us :)

Sounds a lot like https://sharefest.me/ :)

Sharefest has been in Alpha for years. Why is that still the case? Is it not under development anymore?

All webRTC apps are like that. I suppose it's because the standard is considered unstable?

Looks cool!

The title is somewhat misleading... Javascript originated delivery is probably more accurate

What's missing?

Sublime Text? More to the point, there's a bunch of stuff in there that I don't want to install. Do I get to choose which programs to install after I download?

As well, WebStorm is only free for thirty days so it doesn't seem like something that should be packaged up like this.

How does it compare Redis?

Redis implements operations against simple in-memory data structures with a network frontend, not a distributed storage/replication system.

Sirius lives at a lower level: you could, for example, use Sirius to build the storage system backing a distributed Redis clone.

The network front-end is key here, especially since the goal of Redis is -- in spirit and in actuality -- to act as a network front-end to in-memory data structures.

It's damn good at it too, but disassociating that network front-end may make sense in the future.

Redis and Sirius target slightly different use cases, although they share the goal of keeping data in memory. For our use case that motivated Sirius' development, we wanted to avoid doing I/O to an external system (even a fast one like Redis) in order to simplify development by having direct access to the data in native datastructures.

Additionally, we found that we needed some custom datastructures to get the performance we needed, so providing application developer control over those datastructures was an important motivation.

Yeah, it just that you wanna make sure the padding variable is not being overridden by some malloc ;)