The Problem With Founders - <AUTHOR> http://techcrunch.com/2014/07/20/the-problem-with-founders <comment><USER4> I have to commend TC for writing an article like this, as they are largely the biggest vehicle for turning founders into Hollywood-esque stars and boasting founders as being disruptive (heck, their own conference is called Disrupt).

The central principle of realizing that there are more people behind a startup and we should cherish them as well, is an absolutely awesome thought!!

I just hope that the vision for how we recognize them is not how the author describes in: "We need to find a way to build up the profile of that quiet army of people who are developing products behind the scenes, the engineers and product managers who took risks to build their founders' dreams." Because that just sounds like what they currently do to founders!

Idea: maybe TC could take the charge and list the founding employees profiles with every company article they write?

<comment><USER5> I like your idea. I expect if they implemented it they would see that the article gets it wrong on a number of levels.

Take any successful company, Google, Intel, Apple, Facebook, LinkedIn, Yahoo!, Microsoft, Boeing, any of them. Now compile a list of the first 10 - <USER2> employees. Now take the net worth for those individuals and compare it to the rest of the world. You'll find it lands north of the 99th percentile.

You can pull out exceptions of course, the sales guy at Sun who was worth several million and lost it all through a series of really poor choices, the Googler who left 6 months in rather than vest that first tranche of stock, the Apple employee who gave up their shares to live a simpler life. But for the most part all of those people have a net worth north of $1M. Ask Charlie Ayers, the original chef at Google if he is mad/bitter/whatever because Larry and Sergey are billionaires and he is just a multimillionaire.

The narrative that founders win and everyone else loses is wrong. You've heard about the abominable failure rate of startups 9 in 10 fail. An employee can get a piece of 10 different startups in 10 years if they move from place to place, vest their 25% of their option and exercise it. A founder is lucky if they get 3 shots at the prize in 10 years. Do the employees who are driving around matching Ferrari's in the Facebook parking lot feel bad that Zuckerberg is worth a lot more than they are? Most of them no, they don't care, they are "rich".

Do founders get the 'fame' ? Sure, is that a good thing or a bad thing? Sometimes it makes you a target. I was amazed at how much Eric Schmidt paid for personal security (its in the 10Q) he can afford it of course but really? You have to hire ex-special forces types because you're too tempting a kidnapping target? I personally would much rather be anonymously wealthy than 'target on your back' wealthy.

One summer I worked at IBM and lost my housing just before my internship was up. I stayed at one of my co-workers places for the last three weeks. He had a computer which he used to monitor the stock market, I helped him enter data into it (which at the time there was no Internet). One evening having just gone through a list of number/value pairs (qty and price) I multiplied them all out in my head and summed them, the result was over $2M. I asked him if that was his savings and he said "yup". I couldn't believe this guy who lived in the same tract house he had been living in for years was a millionaire. Where was the fancy car? the lavish furnishings? None of that. I asked him what it was like, he said, "I worry less about the future than I did before."

My point is that the ecosystem that is Silicon valley creates a lot of those kinds of people. People who don't get caught up in the razmatazz and just save money when they can, diversify when their stock value goes up, and accumulate over time. They are usually "employee" types and not "founder" types though.

<comment><USER6> The Valley has changed. If you started in the 1990s, you got real equity and housing costs were low. You could get into the low millions just by working hard and living frugally. It was a different time-- more egalitarian and far more engineer-driven.

The question is: if you're 22-25 now and move into the Bay, do you have a good chance of ending up a made man (or woman)? The answer is "no". It's been overrun by MBA culture and has severe founder quality problems and I don't think it's salvageable.

<comment><USER5> The valley constantly changes.

Your question is identical to the one posed in 1999 during the first 'bubble' people saying "Oh but now it has gotten so inflated and ridiculous, someone moving here now doesn't stand a chance" and yet here we are in 2014 with a bunch of new LinkedIn, Google, Facebook, and other millionaires. In '84 when I moved here it was the 'great semiconductor dying' where places like Intel argued they were a good company because they were losing money less quickly than any other semiconductor company. Or had you been here in the 70's when cutbacks on defense work was the 'death knell' for the valley. What the observations miss is that the value is in the _change_ not in the _status quo_.

If you move here as a 22 - 25 year old I think you continue to have a better chance of becoming financially independent than you would elsewhere. But its not a 'done deal', there is always luck, choices, and opportunities. Every time something fundamental changes, it creates a shift. In the last part of the 20th century it was the arrival of cheap computation, in the early 21st century the arrival of the Internet. Both created big shifts and opened up big opportunities to create value and wealth. They appear and vanish. I find it amusing that much of the money that went into my house came from Sun stock which, when I sold the last bit was worth very little, but during that time when it was valuable it became a part of my house. I see three candidates leading the next wave, adding autonomy to normally non-autonomous products (cars, trucks, lawn mowers), ubiquitous sensing to achieve better efficiencies in raw material usage (farming, manufacturing, housing, etc) and information economics (changing the way information is priced, bought, and sold). These are all emerging even as we're exploiting the tail end of social and Internet everywhere.

But here is the thing, if your 22, thing about being 'made' when you are 52, not when you are 25. And if you are suddenly "rich" at 25 think about how to make sure you are still rich enough when you're done working for others.

</comment></comment></comment></comment><comment><USER7> So much nonsense in one article. If you think the "bar is so much lower" to becoming a founder then stop whining about being one of the forgotten early employees and get off your ass and start a company for the right reasons: finding a market opportunity and making money from it. If you can't or won't, then you can't expect the rewards.

Early employees are important, and should be given credit and fair payment for their work, but their risk profile is far, far less than the founders and investors. Investors stand to lose their investment (which is an accumulation of work) and the founders can lose money, reputation, and time. In my last business I lost hundreds of thousands of dollars of my own money and five year's 24/7 sweat. Every employee walked away.

<comment><USER8> I think the article is complaining precisely because many people are doing that; they refuse to be one of the forgotten early employees and start their own company. As a result, you get a glut of startups, a massive shortage of engineers (particularly in the startup ecosystem), and a series-A crunch as many of these startups fail to gain traction.

The market may fix everything in the long run, but usually it does so through failure. The article seems like it's trying to get ahead of the curve and glorify being an early employee before it's popular.

(Side note: I'm currently trying my own thing, but I wonder how well economically I would do by offering to be an early employee for high [>10%] equity stakes. My guess is I would get - reluctantly - laughed out of the office, but that's okay, because I've got my own thing and am probably more well-funded with better tech skills than they are.)

</comment></comment><comment><USER9> I'd like to add that while I totally admire Gideon Lewis-Kraus and Nikki Durkin for the struggles they went through, their stories aren't the average experience of a founder in today's Bay Area ecosystem.

For every founder that has gotten seed funding, there are several times that number that haven't gotten anything. I made it to a startup accelerator, so I know that already puts me above the average experience. But for the others...

Maybe they tried it for a year and burned through their life savings. Maybe they worked on nights and weekends and are still struggling. Maybe they quit their jobs, talked to every investor they could, and are still trying. That's the average experience.

And don't forget about the world beyond the Bay Area...

</comment><comment><USER10> _We also need to shift our culture and empower our employees to build their own careers, networks, and ultimately, dreams. Companies should take the opportunity to encourage their engineers to give technical talks, release open-source code libraries, and receive external credit for the work that they are doing._

I get the sense from this article that every startup can be reduced to a lot of engineers chained to benches with a founder (or cofounders) standing gloriously in the limelight, cracking the whip between press interviews and investor meetings at the Battery.

One thought is that the founding team at a startup is likely to be entrepreneurial and initiative-taking enough to seek out these opportunities for themselves, should they want them; though I appreciate the nod to startups who remain in 'stealth' mode indefinitely, leaving a puzzling blur on someone's resume.

Another, that I definitely see folks out and about from startups who are not the founding team, but then I go to technical events and read technical publications, neither of which tend to fawn over the CEO to the exclusion of all else. Should we glorify the Rails developer who built a CRUD app over the CEO who found the money to pay the team, test the app in the market, and ultimately grow the business? No, we should reward ingenuity regardless of the title of the person behind it. But HN does a pretty good job of that, and at its core I think this article is just an argument against shallow tech journalists who prefer a tidy story about college roommates over a messy bunch of talented folks who did great work.

<comment><USER11> _I get the sense from this article that every startup can be reduced to a lot of engineers chained to benches with a founder (or cofounders) standing gloriously in the limelight, cracking the whip between press interviews and investor meetings at the Battery._

Yes, that's the image the author wants you to take away. It doesn't make much sense though.

For starters, what on earth chains these engineers to their benches?

Startup engineers get weekly emails from recruiters and hiring managers at competitors (and often partners, which really stinks). The pay, perks, and work environments available to them are tremendous and only getting better. If they don't like where they're at, they can be in another job in a fortnight. And if that's no good, they can jump onto the next opportunity until they find a good fit.

For this reason as a founder that went through YC and took a startup from 0 to acquisition in 3 years, I never once felt like I had anything resembling leverage over the engineers in our company. Just the opposite, I spent a lot of time thinking about how to give them the best possible work experience because I knew if I didn't, someone else would.

</comment></comment><comment><USER12> There's so much that's wrong with this post it's hard to know where to begin.

> The secret of Silicon Valley is that the benefits of working at a startup > accrues almost entirely to the founders, and that's why people repeat the > advice to just go start a business.

This is simply not true in today's environment. Most startups fail so at a typical startup, there is no upside for employees _or_ founders. Funding, however, is plentiful and most of that funding is directed to employee salaries. So who is benefiting the most at the average startup? The engineers paid well into the six-figures to work on modest CRUD apps regardless of said app's ability to drive sufficient revenue to sustain a real business.

In other parts of the post the author suggests that engineers (and other non- founders) aren't compensated appropriately, but his argument isn't convincing. Lots of early stage startups (perhaps the majority) don't generate enough cash to fund operations and many won't any time soon if ever. Just how much should folks be paid at a company that, without investment dollars, wouldn't be able to make payroll?

> There is a reason it is hard to hire in Silicon Valley today, and it isn't > just that there are a lot of startups. It's because engineers and other > creators are realizing that the cards are stacked against them unless they > are the ones in charge.

There are _a lot_ of reasons companies find it hard to hire in Silicon Valley today. They're too picky and/or focused on "culture." They can't pay market salary. Lots of companies are uninspiring and thus unattractive. Many startups fail at retention. Not everyone wants to work at a startup or live in an area with a high cost of living. And so on and so forth.

Absent hard numbers to back up the claim, the author fails to present evidence is there that there isn't enough talent primarily because individuals are leaving the labor force to start their own companies.

> Founders are not normal people in any of the ways that matter of course. For > them, the benefits of building a business are many-fold. They can connect > with journalists, advisors, mentors, new business partners, and most > importantly, investors...

Note how the author left out "customers." Interestingly, the word doesn't appear anywhere in this article, nor do the words "sales", "revenue", "cashflow" or "profit." For a post that does an awful lot of complaining about how the fruits of startup success are divvied up, I think it's telling that the author completely ignored the things that make a company successful.

</comment><comment><USER13> I agree mostly with the article, but early stage employees are also investing in themselves.

Young product managers at Google or Microsoft don't get the opportunity to work on big problems. The few young people I've met tend to lack the macro thinking on what makes a product successful. Why talking to users is so important. Why defining a problem is so important. Why retention is more important than growth. Why cohorts are so important and why analytics can be misleading.

With young engineers, they tend to lack the understanding on why striving for simplicity is important. Why thinking in iterations is important. Why writing tests are important. Why the best engineering in the world can't save a product that doesn't solve real problems.

Big companies do teach you these things, but not at the pace of a real startup.

<comment><USER8> My experience - having worked at both Google and in the startup scene - <USER3> that young PMs at Google/Microsoft actually get to work on much bigger problems and have a much better understanding of the macro scene than startup founders. At Google, it's not uncommon to hear "Can't we just buy [famous startup X]?" or "Figure out the benefit for users, and if it turns out to be useful for a large number of people, we'll see if the lawyers and lobbyists can get the law changed" or "We'll just throw 65,000 machines at the problem." As a result, there's a presumption that problems are _solvable_ if we just think really hard and identify the incentives of everybody in the system. Few startups have this privilege.

Where Google really falls down compared to a startup is in _micro_ -level thinking. A PM at Google may understand how a hundred million users behave in the aggregate, but fail to understand how to change _one_ user's behavior. When your sole work experience is at a powerful corporation, you start assuming that people will take your phone calls, and you don't develop the skills of how to cold-call an ambivalent prospect, or how to empathize with a minority user who is really frustrated, or how to focus and prioritize on only the tasks that you can make a real impact on.

For engineers, I'd say Google (and presumably Microsoft) engineers understand far better than a startup why simplicity is important. The codebase, after all, is orders of magnitude bigger and harder to understand. And iterations and tests are common practice as well. What a Google engineer does not know is how to stare at a blank editor window and, in the next 3-4 hours, get something cool up on the screen. They don't know how to duct-tape open source components together into a working, if imperfect, system.

</comment></comment><comment><USER14> Articles like these always repeat it is hard to hire in the SV. I got a few interviews to do remote working for such startups and some of them said it was not possible to work with me only four days per week (I'd like a part time job). If talent is so rare, why is it better to go with zero hours instead of four days ? (Or maybe I just suck at something they don't want to say and telling me about the part-time requirement is easier.)

</comment><comment><USER15> it is like, if you have standup comedian talent , people around you will notice invariably and force you to enter into the arena, similarly if you possess entrepreneurship skill obviously including your family can support you... there you take the first step...otherwise enjoy the world of piece...

</comment><comment><USER16> Off topic: Clothing brand "banana republics" just released a summer line called the startup guy. Even a clothing line is catching up to the phenomenon of "Just start a company"

[http://venturebeat.com/2014/07/20/startup-guy-fashion-is- lit...](http://venturebeat.com/2014/07/20/startup-guy-fashion-is-literally-a- style-in-banana-republics-summer-line/)</comment>


Message Passing and the Actor Model - <AUTHOR> http://dist-prog-book.com/chapter/3/message-passing.html <comment><USER2> The article doesn't mention [Vert.x]([http://vertx.io/](http://vertx.io/)), another JVM library/framework (also works outside of the JVM with Javascript for example) that is loosely based on the actor model. And now with Kotlin coroutine support, they've managed to abstract away a lot of the nodejs like callbacks that clutter up your code - you still need to be aware of what's happening wrt callbacks and such, but it makes your code a lot nicer: [http://vertx.io/docs/vertx-lang-kotlin- coroutines/kotlin/#_g...](http://vertx.io/docs/vertx-lang-kotlin- coroutines/kotlin/#_getting_one_shot_asynchronous_results)

<comment><USER3> Thanks for pointing this out. I've never heard of Vert.x, but I will check it out and see if it seems worth including when I revisit this chapter in the future.

</comment></comment><comment><USER4> I have coded one significantly large system using Akka. I think conceptually, actors are quite simple and powerful. But in practice with Akka, I hated the fact that I couldn't just set a breakpoint and just follow a message all the way through the system via multiple F7's. Every time I got to a "send" call, I would need to find out which of the other 200 actors in the code actually dealt with that message, set another breakpoint, and keep going. Because all you have at runtime is an ActorRef which could really be anything, and all the sends are asynchronous. This was perhaps in large part due to the fact that there was a lot of Akka 101 learning going on during early development so people went a bit crazy with actorifying everything. If in doubt, create a new actor. Because erlang, resilience, Telcos use it, supervisor hierarchies, self healing, and a blog I read last week. Questioning it was a case of the emperor's new clothes. Interestingly none of the big ticket things that Akka was sold to the dev team on ever eventuated.

A while into the project, my team and I were responsible for delivering a subcomponent within the system. We did so with extreme prejudice to only using actors at the very edges and entry points where a bit of asynchronicity was required. But everything within the service boundary was just plain old Java. This was the easiest to understand and maintain part of the system, as attested by another team who we handed over the entire codebase to. Guess which part had the least bugs? Most extensible?

I don't know if akka has improved since then, but the debug workflow was such a departure from the normal way of doing things on the JVM it was enough to put me off and then steer clear of it in general. There are definitely other patterns and libraries I would reach for first.

<comment><USER5> I have come to realize that breakpoint style debugging should be avoided. Atleast for people working on Services. Prefer logging, or other variants like Event History, State Change history, etc.

<comment><USER6> Why?

<comment><USER7> Makes it easier to jump to distributed systems that span multiple processes or machines, where you can't just set a breakpoint. Also makes it easier to debug production systems, where you may have logs but can't jump back in time to attach a debugger.

</comment></comment></comment></comment><comment><USER8> I'd like to mention actix, it is an actor framework for Rust language. it is single process at the moment, but distributed version is in development.

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

</comment><comment><USER9> Is this a good time to mention concurrentlua, a reimplementation of Erlang's concurrency model in Lua, using coroutines to model processes? [https://github.com/lefcha/concurrentlua](https://github.com/lefcha/concurrentlua)

It has not seen a lot development over the past ... couple of years, but it worked quite nicely when I last tried it.

</comment><comment><USER10> I was hoping to see a mention of Pony which looks like a promising language based on the actor model.

<comment><USER11> Relating Pony to some of the languages mentioned, two that seem immediately comparable are Akka and Erlang.

" _Akka's receive operation defines a global message handler which doesn't block on the receipt of no matching messages, and is instead only triggered when a matching message can be processed. It also will not leave a message in an actor's mailbox if there is no matching pattern to handle the message. The message will simply be discarded and an event will be published to the system._ "

" _[In Erlang,] receive statements have some notion of defining acceptable messages, usually based on patterns, conditionals or types. If a message is matched, corresponding code is evaluated, but otherwise the actor simply blocks until it gets a message that it knows how to handle._ "

Pony's message passing is syntactically similar to its methods, with a "be" (for "behavior") keyword introducing a handler rather than "fun". As a result, the message receive operation is global, like Akka, but the type system ensures that an actor cannot be sent a message it does not recognize. These are both different from Erlang, which has a local receive operation. An Erlang process, upon receiving an A message, can call another receive statement and block only looking for B messages. At that point, any incoming A messages will queue up. That has always seemed to me to be a good way to write deadlocks without realizing it.

Pony is otherwise similar to a typed Erlang that compiles to machine code and doesn't (currently) have process monitoring. [:-(]

There was some discussion about distributed Pony, but it has rather strong semantics for message passing, which would require a rather complex underlying protocol. [I'd rather have simple distributed messages and handle failures at the program level.]

[I only have experience with Erlang and Pony; I'm hoping my description of Akka is true from the discussion in the post.]

<comment><USER12> Pony is a bit different to a typed Erlang though:

* Pony has two message passing options: copy or share (by ref). Both are safe, Erlang does only copy.

* Pony is non-blocking only, there are no blocking calls in any stdlib function.

* Erlang supports no native threads, only green threads. So it favors IO over CPU, distributed computing on different cores is only via distributed nodes.

* Pony supports native threads, but no distributed actors on different hosts yet.

* Pony is massively faster, uses much less memory, and has better cleanup via a clever GC protocol.

</comment></comment></comment><comment><USER13> From a quick skim of it I don't see any mention of the real difficulty I have encountered with the Actor model in practice: managing imbalanced actor workloads.

If you consider a simple chain of actors that do some work and then send on a result to a next actor that then does some more work:

        A -> B -> C -> D

Suppose something (anything) happens that make messages to B take slightly longer to process than the rate at which A is sending them. The result is that B's message inbox expands indefinitely. One of two things will happen depending on the queuing model: either A will block on send because B refuses to accept another message, or B will simply run out of memory from too many pending messages.

This of course, is just the linear scenario. Consider a complex network where there may even be cycles (something D does could somehow indirectly result in a message coming back to A). You've essentially got a completely unstable, unpredictable system. The only way to avoid it is to ensure that every actor is massively over-resourced so that it can never fall behind on processing its messages.

Of course, the second stage of this is that you start designing scalable actor "pools" where more than one actor can service messages and you can scale the size of the pool up and down. But this is at the cost of adding even more dynamic, unpredictable behaviour, and to some extent you just lost the simplicity you were trying to gain by using Actors in the first place.

I'm curious if any thoughts from more experienced folks about how to handle these issues!

<comment><USER14> There's a lot of literature on this in the Erlang world. This post is a very thorough summary of the various solutions available:

[https://ferd.ca/handling-overload.html](https://ferd.ca/handling- overload.html)

I don't find that kind of fully async processing pipeline very idiomatic TBH, at least in Erlang - more typically, every request would be its own actor, and do blocking requests to other actors that own shared resources.

<comment><USER13> Thank you for the insightful comments. That link looks perfect (down to the point of having a diagram with a->b->c->d just like mine!).

The idea of each request being its own actor being more idiomatic is intriguing. Naively though does it really solve the problem? Don't you just end up with an overflow of actors now instead of an overflow of one actor's inbox?

<comment><USER15> In Erlang the actors are lightweight processes are much smaller than OS threads. I wouldn't worry.

<comment><USER13> Right, but in my scenario (and I appreciate perhaps this means I'm "doing it wrong"), the messages themselves have a fairly heavy payload (around 800 bytes). Given that, whether I'm spinning up an actor or a message, if it can't be processed quickly it's consuming a non trivial chunk of memory.

<comment><USER15> I wouldn't say you are doing anything wrong (or, at least I couldn't say that for certain without knowing more about your problem domain :) ).

However, I also don't think you have to worry about the message payloads being too large. In Erlang, normally objects are copied between processes. However, for large objects (>64 bytes) they are put in a shared heap, and only the pointers are copied between processes[0].

[0] [https://hamidreza-s.github.io/erlang%20garbage%20collection%...](https://hamidreza-s.github.io/erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang- garbage-collection-details-and-why-it-matters.html)

</comment></comment></comment></comment></comment></comment><comment><USER16> I have been wondering about this past couple of days.

Does kafka streams make Actor Model obsolete? What can you do with actors that you can't with kafka streams if you were starting a project from ground up.

<comment><USER17> They are different worlds.. each actor would be analogous to an independent stream app; or one stream app with lots of KStream/KTable "components", which feels like an anti-pattern.

</comment></comment><comment><USER18> I live and breathe this stuff. Started working with Elixir more recently but have worked with Akka for years. IMO BEAMVM is a great piece of technology and is worth looking at.

</comment><comment><USER19> Is there an index to this book I'm not seeing? I see the directories, but not seeing an overall index. A bit hard to navigate.

<comment><USER20> If you click on "Chapters" it takes you to a directory listing of the chapters, click on a chapter link and it takes you to another directory listing of pages. Click on a page link and it takes you to an actual chapter.

It appears that the "book" still needs a fair amount of polishing to be navigable.

<comment><USER21> See my reply to OP but here is the GH: [https://github.com/heathermiller/dist- prog-book](https://github.com/heathermiller/dist-prog-book)

</comment></comment></comment><comment><USER22> > 59 minutes read

Is this actually correct? I am inclined to think not but it is difficult to judge just from scrolling through it quickly.

<comment><USER21> Im firmly against these "X minutes to read" estimates because the amount of time it takes to read something is highly dependent on many variables (on both the reader side and article side). I would much rather have a "Short, Medium, Long, Novel" kind of scale which is simply a scaled word count of some kind.

</comment></comment><comment><USER23> The root of your book's domain (/) has the test page for tufte.css. The content itself is great!

</comment><comment><USER24> I recall that Microsoft Azure Service Fabric SDK is also based on the Actor Model.

<comment><USER25> MS has [https://dotnet.github.io/orleans/](https://dotnet.github.io/orleans/) which is an interesting take on the actor model.

<comment><USER26> This became Service Fabric

</comment></comment></comment><comment><USER27> I haven't given myself the opportunity to sit down and play with an actor model. But in the meantime, despite reading literature such as this, I have trouble envisioning what it actually entails day-to-day.

I think of my experience with channel-based communication in Clojure, Go, and even Rust's mpsc. And every time I feel an instant feeling of debt because I know I'm just one or two more channels away from misunderstanding the execution of my own application. Having to take out pencil and paper to reason about why messages are bottlenecking in this component or why I was wrong when I thought I knew how my application worked.

For example, we ripped out all of our channels in our Go application and replaced them with a couple mutexes.

When I read about actors, I get flashbacks to some of my worst struggles with channels. Where our application is split into disparate agents that everyone has to eventually map out on a whiteboard to understand even basic runtime behavior.

I owe it to myself to try it out, but I can't help but be discouraged by what I think they are. Can someone clarify? What does the actor model actually mean for your day-to-day code compared to futures, for example?

<comment><USER28> I would spend some time experimenting with Erlang or Elixir. The thing that really made the actor model "click" for me was how each actor in Erlang is just a process (green thread basically). The only way to communicate between processes/actors is message passing, and the way you end up constructing software is by modeling individual tasks and responsibilities of your application in terms of processes. The way processes are constructed in Erlang/Elixir allow you to pattern match on messages to selectively receive or prioritize messages, and discard others. A process can be written in such a way that it changes from one role to another just by being sent a message, or from one state to another (in the case of finite state machines and the like).

A typical example of how it gets applied might be a web server, where each HTTP request is handled by its own process, and potentially delegating multiple tasks concurrently to other processes in the background which handle queuing and executing work associated with that request. You might have pipelines of processes, each responsible for some specific task/transformation before handing off work to the next stage in the pipeline. On top of that Erlang/Elixir provide supervision, where components of the system are started/monitored by a special process type called a supervisor, which will restart its children when failure occurs, and if a set of conditions fail, will itself be restarted by its parent supervisor. So your application ends up structured as a tree of supervisors and worker processes, where components of the application are branches of the tree, and can be isolated from the failure of other components.

Hopefully that helps give you an idea of how the model plays out in practice. I would definitely recommend playing around with either Erlang or Elixir, they are a lot of fun, and it really changes the way you think - at least it did for me.

<comment><USER29> Why it is necessary to discard messages? Isn't it a sign of bad design when resources have to be spend to create and pass a message that is ultimately discarded?

<comment><USER14> I think it's just a bit badly worded. You don't normally throw them away, you leave them in the queue for later.

For instance if you have a process that gets requests and writes stuff to DB, while processing a request you can send a message to the DB, then use a selective receive to match on the response from the DB while ignoring all other messages (you'll deal with them later i.e. when you fetch the next request to process).

<comment><USER29> So "discard" means to post messages to own message queue? If so it seems like an awkward pattern that essentially implements a priority queue.

<comment><USER14> No, messages that don't match are not dequeued in the first place. I don't know why the other poster used the word discard.</comment></comment></comment></comment></comment></comment>


Delhi gang-rape victim dies in hospital in Singapore - <AUTHOR> http://www.bbc.co.uk/news/world-asia-india-20860569 <comment><USER2> That adds murder charges to the criminals. Apparently one of the rapist who was the most active in this crime was a juvenile. It might be the case the the protectors of these criminals are trying to put the maximum blame on this juvenile guy so that others escape easily and being a juvenile he too probably will be let off easily.

The whole incidence and exposed India's failure in multiple spheres. 1\. Government has lost all it's credibility. 2\. Police force is not being looked as protectors of law but mere goons in uniform. 3\. Overall law enforcement has seen it's low in this case and many other cases.

</comment><comment><USER3> Extremely sad day for the whole humanity. May her soul rest in peace.

</comment><comment><USER4> Very sad but I fail to see how this belongs on HN.

</comment><comment><USER5> Why is this on HN?

</comment><comment><USER6> Sad as it may be, why is this getting upvoted? This is very VERY far away from the posting guidelines. Anyways, carry on...</comment>


Show HN: Caonima – A Proxy in the Party - <AUTHOR> https://caonima.io <comment><AUTHOR> Caonima provides Shadowsocks as a service. You can think of Shadowsocks as a SOCKS5-based proxy implementation with an extension mechanism. In China, for example, you will want to install and enable the obfuscation plugin to avoid being flagged by the Great Firewall. Like a VPN, a Shadowsocks installation is your gateway to the open Internet in places where access to the network is restricted, whether due to censorship or net neutrality violations. Caonima grew out of my needs as a frequent China traveler. Current status is a minimally viable prototype servicing a handful of users. At this stage I'm interested in collecting feedback and assessing the service's ability to answer the needs of a broader audience. In return, and for the time being, the service is provided for free.

</comment><comment><USER2> I'm not in your target market but, if I were, answering these questions on the home page might reduce the chance of me bouncing from the home page before registering:

1) What devices can I use this on? (maybe with links to Potatso Lite for iOS, and Shadowsocks for Android)?

2) What plugins do you support (e.g. kcptun)?

3) Where are the servers located? (might reassure people about throughput and latency)

<comment><AUTHOR> These are really good points. Thank you. Currently, Caonima is optimized for China, so our VPS is located in Japan and the use of the obfuscation plugin is required. After registering, users get a link with their client configuration. Users can connect with any device on which they managed to install the Shadowsocks client and the obfuscation plugin. This seems to be a pain point. Some users do not get past that stage.

Caonima provides a ready-to-use server connection. For client installation, we refer our users to the official Shadowsocks channels. Caonima is compatible with the subset of Shadowsocks clients that support the SIP003 plugins ([https://shadowsocks.org/en/spec/Plugin.html](https://shadowsocks.org/en/spec/Plugin.html)). In other words, the better maintained ones, like the C libev implementation. Shadowsocks has a good installation story on Android, too, with the app store and configuration via QR code or paste link. Last time I checked, Potatso on iOS was not supporting the SIP003 plugins.

With Caonima, I was able to watch Youtube videos in China without lag. If there will be demand, we will provide kcptun connections for further optimization.

So here are some questions to which I have no answers yet. Who needs Shadowsocks as a service? People who travel to destinations where the Internet is restricted, and for which the installation and maintenance of a Shadowsocks server is overkill? Expats who expect the best speed and performance from their proxy? ISP customers who suffer from net neutrality violations? Organisations that do business with China, whose employees travel to China, and who might benefit from a lightweight solution?

Ultimately, I hope that the service can prove beneficial to its target audience. It's true that I don't know yet who that is, but I do know that it grows everyday, unfortunately. We live in a world where open, unfettered access to the Internet is becoming less rather than more self-evident.

</comment></comment><comment><USER3> I tried ssh tunneling in Beijing. it was only usable for a few minutes, then they obviously detected I was using it for http. And the speed was slowed down to an unusable level.

I searched, there are tools that can hide the real message in fake http messages.

How does this tool obfuscate the traffic?

<comment><AUTHOR> Via special purpose plugins.

Simple obfuscation: [https://github.com/shadowsocks/simple- obfs](https://github.com/shadowsocks/simple-obfs) Or GoQuiet: [https://github.com/cbeuw/GoQuiet](https://github.com/cbeuw/GoQuiet)</comment></comment>


Signal Desktop - <AUTHOR> https://whispersystems.org/blog/signal-desktop/ <comment><USER2> I'm feeling dirty, because I don't like to be that negative, especially if we're talking open-source software. And I feel that I kinda hold this project to higher standards: If I compare this to WhatsApp/Telegram/Threema/Whatever, I inheritently, somewhat subconciously expect more from Signal.

And I'm disappointed. I tend to repeat the 'central server' and 'a phone number is not an address and not public information, it certainly is no identity' criticism.

When I read the headline/title, I thought 'Now maybe that would be enough to be ~good enough~ to ditch Telegram' in spite of these problems (which Telegram has as well, ofc). But really. A Chrome app. And works only (yeah, I think I said it before: Phone numbers suck) as a secondary client. And only if the first client is Android?

I seriously don't get it. And it certainly is not for me: I don't like that browser (I do have it installed for testing and to follow it at times, but there's no 'app' I'd run in Chrome). I don't want to tie something to my phone and I don't think that it should matter what platform my handset runs on - SailfishOS looks nice, FxOS progresses slow but ticks a good number of boxes for me.

Full circle to the first line: I don't _like_ to be negative and the headline gave me hope for a couple seconds. Unfortunately this release just deepened my belief that Signal wasn't meant to be for me.

<comment><USER3> If we were going to rank our priorities, they would be in this order:

1) Make mass surveillance impossible.

2) Stop targeted attacks against crypto nerds.

It's not that we don't find #2 laudable, but optimizing for #1 takes precedence when we're making decisions.

If you don't want to use your phone number, don't use it. You can register with any GV, Twilio, Voicepulse, or other throwaway VoIP number.

If you don't want to run Chrome, use Chromium instead.

If you don't want to use Google Play Services, use GcmCore.

The world you want this software for is not the world that everyone else lives in. You can certainly make it work in that world with a little effort, but because of how we've prioritized our objectives, that's not the default experience.

<comment><USER4> What is GcmCore? It doesn't show up on ddg or google.

<comment><USER5> It's GmsCore, moxie typo'd. However you can also install via F-Droid by adding this repo [https://fdroid.eutopia.cz](https://fdroid.eutopia.cz)

Moxie is probably going to hate you for it, but it works very well and doesn't require Google Services or anything else.

<comment><USER6> Using that websocket stuff instead of Play Services or GmsCore will make receiving Signal calls impossible.

</comment></comment></comment></comment></comment><comment><USER7> > Signal Desktop is a Chrome app

That surprises me. I don't trust Chrome for confidentiality; I assume it collects data for Google and I don't know that it protects my data from others.

If Chrome isn't trustworthy for confidentiality, it would seem to fatally cripple the security of Signal Desktop. However, I believe the people at Whisper Systems would see that obvious flaw so I suspect that I'm misunderstanding something - what is it?

<comment><USER8> Whisper Systems has a track record of prioritizing 'good enough' ease-of-use ahead of 'perfect' security as a practical way of expanding its user base.

Edit: Tried to word the above most neutrally; I believe this approach has both pros and cons.

<comment><USER9> > Whisper Systems has a track record of prioritizing 'good enough' ease-of-use > ahead of 'perfect' security

Why is Telegram always under for their flawed security challenge despite the good-enough track record then? They also have perfect usability, native apps, 3rd party clients, etc. If the security is not the first priority then Signal isn't very attractive compared to the competition I think.

<comment><USER10> Telegram is closed source so we can't verify that they implemented encryption properly, and only Secret Chats have the messages encrypted.

[https://telegram.org/faq#q-so-how-do-you-encrypt- data](https://telegram.org/faq#q-so-how-do-you-encrypt-data)

<comment><USER11> I thought the Telegram client is open-source, it's even on F-droid. The server side being open or closed source is meaningless:

1\. In Telegram's threat model the servers are not trusted.

2\. You can't verify server side code anyway.

<comment><USER12> The Telegram client can just barely be considered Open Source, see the discussion at [https://github.com/DrKLO/Telegram/pull/76](https://github.com/DrKLO/Telegram/pull/76)

<comment><USER11> F-droid builds those parts separately from source.

> The official source code of the app contains binary blobs, so this tracks a > fork which builds those from source. Hence, versions might become available > with a certain lag.

[https://f-droid.org/repository/browse/?fdid=org.telegram.mes...](https://f-droid.org/repository/browse/?fdid=org.telegram.messenger)

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Loving moxie's namedropping of oldschool revolutionaries:

Maria (Masha) Alexandrovna Kolenkina was a Russian socialist revolutionary from a merchant family in Temzhuk, a small town on the Sea of Azov. (1850-1926) Vera Ivanovna Zasulich was a Russian Menshevik writer and revolutionary. (1849-1919) Nestor Ivanovych Makhno or Bat'ko Makhno was a Ukrainian anarcho-communist revolutionary and the commander of an independent anarchist army in Ukraine during the Russian Civil War of 1917–1922. (1888-1934) (all above from Wikipedia)

<comment><USER14> Oldschool Communist revolutionaries, to be exact. Yeah, it's no mystery where Moxie's politics lie given those allusions and the not-a-company company, eat together, do push ups together, open salary policies.

<comment><USER15> Fortunately for most of the human population, the politics of the author of the software we use isn't really a consideration.

<comment><USER16> I'm sure most people wouldn't use software created by Nazis. Considering Communism has arguably worse track record, I would definitely avoid any software created by its proponents if it's at all possible.

<comment><USER17> > I'm sure most people wouldn't use software created by Nazis

Best selling car of all time; star of several (very popular) movies: [http://www.bbc.com/culture/story/20130830-the-nazi-car-we- ca...](http://www.bbc.com/culture/story/20130830-the-nazi-car-we-came-to-love)

</comment></comment></comment></comment></comment><comment><USER18> I don't understand why it prompts me to invite other people after putting me in line. Why would I email/tweet my friends to join this service if it isn't even ready for me? Seems rude to bother a friend with joining an internet line just so that I can get a better position in the line.

I love signal on android and have been looking forward to this, kind of rubs me the wrong way when I'm put in "line"

<comment><USER19> The app is still in beta testing. I think this is their way to drum up support.

Forces all the die-hards who want in to try and get some people interested.

An app like this is only as useful as the number of people who use it.

<comment><USER20> Invite them to... not use it? That seems like a solid way to turn people off from using a service, not a way get them excited about it.

<comment><USER21> I don't feel strongly about the practice either way, but you're also indirectly prioritizing users who are most willing to share the product. So they're hoping their early users are also those most willing to spread. The "connectors" of the products ecosystem.

<comment><USER20> You're prioritizing users who are willing to spam their friends about a product they can't even use.

I would be _far_ more likely to tell my friends about the product if I could actually use it and be able to vouch for it (as I have with the mobile version of TextSecure/Signal).

Forcing me to get my friends to visit a page where they will find out about an application they can't even use is just annoying.

</comment></comment></comment></comment></comment><comment><USER22> Why incentivize spamming my friends with links before I've even seen the app, only to refer them to a waiting line? Sure, launch day momentum and all that, but I wish that as an entity that wants to be "the good guys", they can find a way to gain a broader audience for their app based on the app itself, not the buzz around it.

On a sidenote, does anyone know who funds their full-timers? [https://whispersystems.org/workworkwork/](https://whispersystems.org/workworkwork/) says they're not VC funded. But then who pays them?

<comment><USER19> They are part of the [Freedom of the Press foundation]([https://freedom.press/](https://freedom.press/)) and have grants from the Shuttleworth foundation

[https://en.wikipedia.org/wiki/Open_Whisper_Systems#Funding](https://en.wikipedia.org/wiki/Open_Whisper_Systems#Funding)

[http://www.knightfoundation.org/grants/201499909/](http://www.knightfoundation.org/grants/201499909/)

[https://www.shuttleworthfoundation.org/fellows/moxie- marlins...](https://www.shuttleworthfoundation.org/fellows/moxie-marlinspike/)

</comment></comment><comment><USER23> I have a question about this...

Say a team of volunteers were willing to spend time to make something like a QT- or GTK-based native desktop application instead.

How much more difficult would this be compared to what they did/used now? (the chrome-app) ?

Also, will it take significantly longer to build such a native app?

Anybody with experience building native apps, please share.

<comment><USER24> What about using something like [http://electron.atom.io](http://electron.atom.io) instead. This would likely be the best of both worlds - native, but not browser-dependent.

<comment><USER25> I really wish this was an Electron / nw.js app instead of a Chrome plugin.

<comment><USER26> I've experimented with this and with a little tweaking it works fine under NW.js's alpha support for running Chrome Apps.

<comment><USER25> I mention it because downloading one file (a nw.js / electron build) is a lot less friction filled than (in some cases) downloading an entire browser just to use one app. There's still people out there who still use Firefox or whatever default browser their OS comes with. Instead of downloading one file, you're now forced to download two.

</comment></comment></comment></comment></comment><comment><USER27> This is a Chrome app. I miss the days of native apps. :(

<comment><USER28> True. Although, I don't understand why it has to be a Chrome app. Why not just a NW.js app? Maybe for the whole "connect with your phone" functionality?

Perhaps somebody could shed some light on this?

<comment><USER29> My guess is it uses Chrome's Native Client [1] for crypto. It's understandable why they might want to do this at this point in time, because the only other way to use native code for crypto in the browser is through the the Web Crypto API [2], which is still very young and implementations aren't very consistent across browsers yet anyways.

[1] [https://developer.chrome.com/native- client](https://developer.chrome.com/native-client)

[2] [http://www.w3.org/TR/WebCryptoAPI/](http://www.w3.org/TR/WebCryptoAPI/)

<comment><USER30> So, effectively, they use native code anyway, but make debugging worse for users?

Great...

</comment></comment></comment></comment><comment><USER31> Why are all these encrypted chat programs (Signal, Telegram, &c.) still centralized and not TOR-style onion-routed?

<comment><USER29> As much as I agree with your overall sentiment, the sad truth is that centralized architectures enable many of the UX affordances that users take for granted today in a modern chat app, many of which are much more difficult, sometimes simply impossible, to implement in a decentralized architecture (think features like automatic contact discovery, offline messaging, etc). Without some of these affordances, a chat app has simply has no chance of gaining widespread adoption in such a competitive landscape. This is why it is very difficult to justify pouring any significant resources into building a decentralized chat app, because too few people will ever end up using it to justify the investment.

For what it's worth, I am the author of a decentralized messaging app myself [1], and have spent _a lot_ of time thinking about stuff like this, and eventually reached this unfortunate conclusion and decided to leave the project at the prototype stage.

[1] [http://toc.im/](http://toc.im/)

<comment><USER32> What kind of things are impossible?

<comment><USER29> The two features I mentioned, automatic contact discovery and robust offline messaging, are examples of features that I have concluded to be impossible to build without some degree of centralization (there are probably more, but those two were the only ones I could recall off the top of my head). Though it is certainly possible that I simply haven't put enough thought into it.

Toc's original goal was to be a decentralized messaging app that makes _no_ compromises in terms of UX compared to a centralized messaging app. Toc managed to tackle decentralized cross platform sync, but to this day I still have no idea how to approach automatic contact discovery and robust offline messaging.

<comment><USER33> Automatic contact discovery is tricky, but the beginnings of one potential solution is I think explored in agl's Pond, using pairings on BN curves?: [https://pond.imperialviolet.org/](https://pond.imperialviolet.org/)

To a point, so is offline messaging. Distributed datastores in general do that kind of thing - there are old implementations over Freenet in particular, and GNUnet as well and other things I think. The _robust_ part is harder: if the client is offline, where's the disk space coming from? Volunteers' (nodes') cache? That needs to be opaque, and so do lookups. What's to stop spammers flooding the network? (Spam, and denial-of-service in general, is a Hard problem to deal with in general even in distributed systems.)

They're not among the hardest problems. Pseudonymity is a huge challenge as the latency gets lower against traffic correlation attacks, and a secure messenger is most definitely up against the kind of threat model that can and will try to pull those off in the wild. Perhaps mixing high and low-latency traffic may help, although it's going to need to be very carefully analysed how much (I believe I2P's design can do that, although I'm not sure if jrand0m ever implemented it in the router).

<comment><USER29> Yes those are definitely not the hardest problems in this space. I was only referring to UX-related features in my original post (i.e. rather than the much more tricky privacy and security related ones), ones that I couldn't figure out how to actually _implement_ in the context of a client-side web app. _Impossible_ was probably too strong of a word to express that.

Thank you for all the interesting ideas and resources though! They'll definitely come in handy when I eventually revisit this space when I have more time later on.

</comment></comment></comment></comment></comment></comment><comment><USER34> All good with the Android, but disappointed this is Chrome. You would think they would have a FF plugin by now!

<comment><USER35> It's easier to build Chrome apps, and they are also more secure. It's one of the reasons Mozilla is trying to move away from the add-on model and adopt WebExtensions. When it does that we should start seeing Chrome/Firefox apps appear likely at the same time. It's why I hope Mozilla dismisses the backlash against the switch because some people can't live without their "deep" themes.

<comment><USER30> It's not just "deep themes".

What if I want thumbnails of tabs on hover?

What if I want the browser UI to be colored in the theme color of the current webpage (similar to chrome mobile)?

I can do that today with FF.

I can't do that with WebExtensions.

</comment></comment></comment><comment><USER36> The join the beta button isn't working? I click and nothing happens.

I looked at the page source, but then I realized I don't know how the fuck javascript works.

<comment><USER37> the button only worked in chrome, not firefox for me

<comment><USER38> same, sigh

</comment></comment></comment><comment><USER39> >Don't leave your friends behind, invite them to signup with this unique link. The more friends that join, the further you will advance in line for the beta.

That's annoying.

<comment><USER20> Even more annoying is that it tells you how many people are ahead of you in line, so you get to watch that number grow as you move further down the list...

I was pretty excited about this when I saw the title, now I'm just annoyed.

</comment></comment><comment><USER40> Note: Android only. Edit: In the sense that it only works with the Android version of the app.

<comment><USER41> Android only on the sense that the ability to provisions two device keys with one account is Android only.

OWS is hiring iOS devs to implement more pieces of this.

<comment><USER42> Yeah, I was disappointed to discover this a while back when I tried to provision an iPad to use the same account as the iPhone.

The failure mode is horrible too, in that messages will just go into the ether. I apparently missed a whole bunch of messages until I deleted Signal off the iPad and reinstalled on the iPhone.

</comment></comment></comment><comment><USER43> This is slightly off-topic, but I hope moxie (or an employee of WhisperSystems - nothing official needed) wouldn't mind chiming in:

Since I loved the fact that I can run my own TextSecure server, I'm wondering why Signal does not run a similar model?

I'm curious which considerations went into this decision.

</comment><comment><USER44> Sadly, as much as I'd like to use Telegram or Signal rather than the usual suspects (sms, whatsapp, facebook messenger), it would require someone on the other end to receive my messages.

The likelihood of convincing my friends/family to use a messaging app that isn't any of the usual suspects is low to none. And none of my bleating about privacy issues will convince them otherwise ("I've got nothing to hide, doesn't bother me").

</comment><comment><USER45> Since when are browser apps "desktop" apps ?

</comment><comment><USER46> I agree with some of the folks here. I have the utmost respect for Signal and Marlinspike but this seems like a weird direction for this to go in. A Chrome app? Tying it to the Chrome App Store? Requiring a Google email for the beta group? Just seems out of place for Signal.

</comment><comment><USER47> Any plans to make a Firefox add-on?

</comment><comment><USER48> Requiring a google email address and chrome for a secure messaging system? Very strange move.

<comment><USER19> They're using Google groups to manage the beta testing program.

Make sense since that's how you sign into the Chrome app store to download the app.

<comment><USER49> "Make sense since that's how you sign into the Chrome app store to download the app."

I don't think it makes any sense at all.

Even if you _do_ use gmail/google in some places (I don't) it's not a given that you want to tie that identity to this app or these activities.

A throwaway google account is getting very difficult since google automatically flags an account with no mobile phone number attached to it as a "suspicious activity" account, immediately forcing you to add a mobile number.

Google is not the Internet. Their app store is not the Internet. I can't believe that the people I know to be behind this project have tied it to google in such a necessary and intimate way.

<comment><USER50> Really, they do that now!? No way am I giving Google my phone number, goddamn. I have gradually drifted away from using any Google services - I guess I won't be creating any new Google accounts in the future, then.

</comment></comment></comment></comment><comment><USER51> How much money do you need to develop and maintain a Firefox version? Can I donate? I don't want to help to enforce this idea that Chrom* is the only browser that can run certain things, is against my believes.

</comment><comment><USER52> Why is there a queue for entering beta when it is possible to get the source and install on Chrome right away?

</comment><comment><USER52> Why do I need a phone number?

<comment><USER53> Yeah, this makes Signal a total non-starter for me. It is doing the same thing WhatsApp does: you need a smartphone to use it. Even the desktop version requires a smartphone to create an account.

If privacy is so important for Signal, why forbid using it without a phone number? It makes no sense.

</comment></comment><comment><USER54> This is slightly off topic but am I the only one surprised at the litany of permissions they require for the android app? Some make sense (like SMS or camera) but device & app history/location/identity/device ID & call info/contacts/calendar/microphone/phone seems like a smash and grab. I saw moxie speak at a conference once and he specifically called out the device id/call information permission as evidence that google doesn't care about your privacy, so why is his privacy-enabling app requiring it?? I thought these were supposed to be the good guys (and girls)? The good guys (and girls) don't do 'collect it all.'

<comment><USER6> > am I the only one surprised

Why not ask your favorite search engine? Definitely faster than creating a HN account ;)

First Google search result: [http://support.whispersystems.org/hc/en- us/articles/21253585...](http://support.whispersystems.org/hc/en- us/articles/212535858-What-are-all-these-permissions-)

</comment></comment><comment><USER55> Why make it a Chrome app instead of a node-webkit app?

<comment><USER56> nw.js is somewhat concerning from a security standpoint, you're always one XSS vulnerability away for arbitrary code execution.

</comment></comment><comment><USER57> I love Signal and advocate it wherever possible. After following along on the GitHub tickets for this project, I'm happy to say thank you and congratulations on the beta release folks!

I'm probably about to ask this on the mailing list soon anyway, but in case there is any hidden knowledge here:

1\. There was talk of server federation long ago. Is this still part of the long term plan?

2\. There was talk of not using a phone number as a required identifier. Is this still part of the long term plan?

</comment><comment><USER58> I got excited about signal after watching this video, which explains pretty well the challenges of encrypted communication and how Signal addresses them (it might be basic stuff for people super familiar with the topic though): [https://www.youtube.com/watch?v=tOMiAeRwpPA](https://www.youtube.com/watch?v=tOMiAeRwpPA)

</comment><comment><USER59> If I wanted someting that looked like skype, I would just use skype. These bubbly colorful interfaces make me sad on the inside :(

</comment><comment><USER60> Why should I use this instead of Jabber/XMPP over TLS? Can someone sell me on this that knows how both work?

Thanks!

<comment><USER61> The differences are:

* XMPP is using addresses with the same format as e-mail addresses (Jabber ID/JID), Signal accounts are bound to your phone number

* Signal has strong end-to-end encryption built-in, for XMPP you need OTR or the recent OMEMO port of Signal's end-to-end crypto magic

* XMPP is federated, where you talk to your server, and it talks to your buddies servers; with Signal everybody talks to WhisperSystems' servers

* XMPP has no decent iOS app, but pretty good multi-device support otherwise

</comment></comment><comment><USER62> Shame that its Android only. Was really looking forward to giving this a try!

<comment><USER3> For now! We're hiring, if you know anyone that wants to help us speed up iOS development: [https://whispersystems.org/workworkwork/](https://whispersystems.org/workworkwork/)

<comment><USER63> Why tie it to a phone at all? Why not have this Chrome app work standalone? Apple's messaging app uses end-to-end encryption _and_ it can be routed to multiple devices. I would expect Signal to strive to attain parity with Apple's offerings.

Also, the naming of this app is pretty disingenuous. This app should be called "Signal Remote", since it's not running the actual Signal comms on my desktop, it's remotely controlling Signal on my phone.

<comment><USER6> Nope, I think you misunderstood something. Your phone does _not_ need to be online for the desktop app to work.

</comment></comment></comment></comment><comment><USER64> I'm assuming this works similarly to WhatsApp Web ([https://web.whatsapp.com/](https://web.whatsapp.com/))

<comment><USER58> And actually, earlier this year, WhatsApp started using the encrpytion protocol developed by the signal folks (Axolotl) to encrypt message data, Which is super cool. (I think group chats and images are still not encrypted, or something) I wonder if in the future Signal will focus on integrating their encryption into other existing chat systems like Facebook messenger, and put the Signal apps on the backburner.

<comment><USER65> The problem I have is when these systems don't indicate whether their session or secure or not. Last time I checked, WhatsApp still didn't have it. This is especially problematic when the system has exceptions like the ones you've described. (Group chats, images, etc.)

Services like LINE also bragged about their secure chat feature, too [0] but honestly, without an active indication of whether their session is secured or not, it's fairly useless and I don't really like this "hide the complicated stuff" attitude that those services seems to be going toward...

[0]: [http://developers.linecorp.com/blog/?p=3679](http://developers.linecorp.com/blog/?p=3679)

</comment></comment></comment><comment><USER63> Call it what it really is: "Signal Phone Remote". This is not Signal Desktop if you need a non-desktop to use it.

<comment><USER6> That name would imply your phone had to be online for the desktop app to work - that's not the case.

<comment><USER63> Oh, that does sound a lot more reasonable and I made an incorrect assumption.

I take it that you still need a phone to make a signal account though?

<comment><USER6> Yep, at least that's how the official version of the chrome app works at the moment, it offers no standalone option.

</comment></comment></comment></comment><comment><USER66> This isn't working for me - the code that is supposed to show up for me to scan doesn't work, I just see:

connecting....

</comment><comment><USER66> This isn't working for me, the code I'm supposed to scan won't show up, just

Connecting....

(I installed from github)

<comment><USER67> EDIT: I apologise, I'm wrong. It appears github has been updated to remove this warning.

and as it pretty says on github, the github repo is confiugred to connect to the development server.

So yea, trying to jump the queue by installing the dev blob from github won't work.

<comment><USER68> I made it working: 1\. Clone the Signal-Desktop Repo 2\. Edit the File: "js/background.js" Line 56 SERVER_URL to '[https://textsecure- service.whispersystems.org'](https://textsecure-service.whispersystems.org') and Line 57 ATTACHMENT_SERVER_URL to '[https://whispersystems-textsecure- attachments.s3.amazonaws.c...](https://whispersystems-textsecure- attachments.s3.amazonaws.com') and save it 3\. Open chrome://extensions/ 4\. Activate Developer mode 5\. Click "Load unpacked extension..." and select the Signal-Desktop directory 6\. Open [https://textsecure- service.whispersystems.org/](https://textsecure-service.whispersystems.org/) and accept the cert (otherwise you won't see the qr code) 7\. Scan the qr code and have fun!

<comment><USER69> > and accept the cert

... sigh... Trusted encryption fail.

Is there some way to verify this cert?

</comment></comment></comment></comment><comment><USER35> I assume it doesn't have video support yet. Any chance it will within a year?

</comment><comment><USER70> I've been looking forward to this! Thanks for all the hard work.

</comment><comment><USER71> The header photo looks like a Windows screen photoshopped into OSX.

</comment><comment><USER72> > Signal Desktop is a Chrome app which links with your [Android] phone,[...]

Unless your "adversary" is not the NSA, I wonder what's the point of encrypting your communications when those coms are taking place on technologies (iOS, Android, Chrome) from companies that are members of the Prism program.

<comment><USER73> 1\. Billions of people live in countries which do not have jurisdiction over Apple, Google, etc.

2\. You should learn more about PRISM before spreading FUD about its victims. I'm strongly critical of the NSA's actions but for all of their abuse, PRISM is not the bogeyman you're making it out to be:

"The PRISM program collects stored internet communications based on demands made to internet companies such as Google Inc. under Section 702 of the FISA Amendments Act of 2008 to turn over any data that match court-approved search terms"

[https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%...](https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%29)

<comment><USER74> > court-approved

Remember, this a secret court, whose judges are likely highly biased in favor the government, with secret proceedings where only the NSA gets to make a case. Not exactly a legitimate safeguard.

I also have reservations about the grandparent comment, but PRISM is still pretty awful.

<comment><USER73> Again, I'm not defending them in any way but all we know about the program is that it allows the kangaroo courts to order searches of information stored on those servers. We have no reason to believe it includes the ability to e.g. compel Google to ship a compromised version of Chrome to a specific user and the fact that the NSA has an entire program to develop and deploy rookits supports that interpretation since it's far more expensive than just asking the company to do it for you.</comment></comment></comment></comment>


Kim Dotcom Answers Questions - <AUTHOR> http://yro.slashdot.org/story/15/07/27/200204/interviews-kim-dotcom-answers-your-questions?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Slashdot%2Fslashdot+%28Slashdot%29 <comment><USER2> _I 'm not involved in Mega anymore. Neither in a managing nor in a shareholder capacity. The company has suffered from a hostile takeover by a Chinese investor who is wanted in China for fraud. He used a number of straw-men and businesses to accumulate more and more Mega shares. Recently his shares have been seized by the NZ government. Which means the NZ government is in control. In addition Hollywood has seized all the Megashares in the family trust that was setup for my children. As a result of this and a number of other confidential issues I don't trust Mega anymore. I don't think your data is safe on Mega anymore. But my non-compete clause is running out at the end of the year and I will create a Mega competitor that is completely open source and non-profit, similar to the Wikipedia model. I want to give everyone free, unlimited and encrypted cloud storage with the help of donations from the community to keep things going._

<comment><USER3> If Dotcom wanted an open-source community-supported file sharing platform that couldn't be taken over by external forces, why did he create the perfect antithesis to that?

Why did he in fact sign an agreement barring him from competing in that sector?

I can't understand how somebody who wants such a perfect world consistently painted himself into a corner from which he couldn't.

<comment><USER4> Maybe for money?

<comment><USER5> Court cases are expensive.

</comment></comment></comment></comment><comment><USER6> [http://www.zdnet.com/article/mega-denies-claims-by-kim- dotco...](http://www.zdnet.com/article/mega-denies-claims-by-kim-dotcom-of-nz- government-control-of-company/)

<comment><USER7> Even if the title is "Mega denies" they either _confirm_ what Dotcom claims or simply don't comment.

Dotcom: "In addition Hollywood has seized all the Megashares in the family trust that was setup for my children."

Mega: "Mega said that it has 13 percent of its shareholdings subject to two freezing orders. A 6 percent holding controlled by Dotcom's estranged wife was frozen in November 2014 by the New Zealand High Court on application by five Hollywood film studios."

How can this be called a "denial" I don't understand.

<comment><USER8> Firstly, the line you quote said "all the" shares, the fact that 13% have been frozen doesn't prove or disprove that statement.

Secondly, Dotcom's main claim was the hostile takeover, his family shares were just a part of that. It could be true that they were frozen but un-true about the rest of his claims.

So yes, it's a denial of his full claims, but maybe (or maybe not) a confirmation of one part of his claims that you pulled out.

That said it's obviously a bunch of PR speak that means nothing. For example this line:

> _" More than 75 percent of shareholders have supported recent equity issues, > so there has not been any 'hostile takeover', _

You could plot a hostile takeover in which the end, winning, result is that you own 75% of the shares, that _is_ the takeover. So having shareholder support when the claim against you is "they took over the company by sneakily getting shareholder control" is irrelevant.

All in all, it's a denial, but not one with any evidence in either direction.

<comment><USER7> All the "shares in the family trust" seized by "Hollywood" (claimed by Dotcom) can be exactly the "6 percent holding controlled by Dotcom's estranged wife (which) was frozen (...) on application by five Hollywood film studios" (stated by Mega).

On another side "The company has suffered from a hostile takeover by a Chinese investor who is wanted in China for fraud." (said by Dotcom) is not commented by Mega at all (unsurprisingly). So what did Mega actually deny? I claim, nothing. It's OK if you consider it enough that they call the statement "a denial" but from my subjective point of view, the press and we, the readers, should not even accept such a name if there's nothing in the statement that denies anything Dotcom claimed. I think you actually agree that nothing was effectively denied, as you also say: "it's obviously a bunch of PR speak that means nothing." So yes, Mega can call it a denial, but I don't understand how anybody else can call it so if he/she reads the content of the statement. Specifically, how can the news agency write the title "Mega denies" and be trusted? It's not the same as "Mega responds."

</comment></comment></comment></comment><comment><USER9> > The company has suffered from a hostile takeover by a Chinese investor who > is wanted in China for fraud. He used a number of straw-men and businesses > to accumulate more and more Mega shares. Recently his shares have been > seized by the NZ government. Which means the NZ government is in control. In > addition Hollywood has seized all the Megashares in the family trust that > was setup for my children.

Huh! I had no idea Mega was publically shared. Why would you do that if your philosophy was supposed to be privacy, not money?

<comment><USER10> It doesn't have to be publicly shared for a hostile take-over to happen. All that has to happen is that your 'investor' shares constitute a majority and that those shares end up in the hands of someone that kicks out the C-suite and replaces them with others.

One way in which this could happen is if the entities holding those shares are bought (so an indirect hostile takeover).

As an example: one of my companies holds shares in another. If I sell the parent company the other shares - and their voting rights - will transfer as well to the new owner. This is because there is no 'change of control' trigger clause in the shareholder agreement of the daughter company, if there were then such a change of control could force the company in the middle to offer its shares to the sitting shareholders of the daughter company.

But even that can still go wrong: the sitting shareholders would have to be able to meet-or-exceed the value placed on the shares and if they can't the shares end up in the hands of others.

</comment></comment><comment><USER11> Can anyone recommend an alternative?

<comment><USER9> 5$ for a 500 gigabyte server, put seafile on it, done.

<comment><USER12> Where can you get a 500GB server for $5?

<comment><USER13> OVH gives me an Atom-based thing with a 500GB disk for £2.98pm.

<comment><USER12> I'm looking on the OVH website, but I don't see it?

<comment><USER14> It's from Kimsufi, OVH's unmanaged, budget offering: [https://www.kimsufi.com/en/](https://www.kimsufi.com/en/)

</comment></comment></comment></comment></comment></comment><comment><USER15> I'm exhausted. Downloading all my data from all "soon-to-be untrusted" services to my external hdd. That's madness.

<comment><USER16> Never trust a single location, be it a service, device or person, unless you don't care about your data. There are tools which can help you keep multiple copies on multiple services and/or devices.</comment></comment>


An Account of the Russian Revolution - Pete-Codes https://www.youtube.com/watch?v=Cqbleas1mmo <comment> Pete-Codes The channel is also Oversimplified - it's actually incredibly detailed.</comment>