Reflections: The ecosystem is moving - <AUTHOR> https://whispersystems.org/blog/the-ecosystem-is-moving/ <comment><AUTHOR> I'll add my thoughts here, since I think a number of people will be disappointed in this post.

There are a number of competing goals when developing software that "the whole world can/will use". And it seems obvious to me that getting the whole world to use a secure, encrypted messenger like Signal (now, Whatsapp) is a noble goal. The obvious competing goal is federation, and the fact that we've failed at improving federated services (e-mail being the best/most important example) is a problem.

Ultimately, Moxie's arguments here hold a lot of sway for me. I think it sucks that constantly-improving services are impossible to address in a federated way, and he's not really offering a solution to that. But instead he presents arguments I hadn't thought about much, which is that perhaps non-federated services can be dramatically better than federated services in the short-term. And in the long term, perhaps we'll move back to federated services; right now, the cost of changing services/ecosystems is very low. So we don't need to be as 'doom-and-gloom' about the fact that Signal does not achieve _all_ the competing goals, because it achieves a number of extremely important goals _right now_ , and we can work on the other goals in the future.

<comment><USER3> It's precisely the fact that Moxie is so credible on this topic that makes his post so frustrating. I believe that he's telling the truth as he sees it, and I believe that he's as well-situated as anyone could be to pull off a white- hat secure messaging system, so if he says it can't be done with federation, it's awfully hard for me to assert that he's wrong.

The problem is that I don't see the point of doing any of this _without_ federation. If we're just using the Internet as a substrate for a bunch of proprietary silo services, then we're just back to the way things were before - walled gardens and media conglomerates and extortionate Bell System-style lock-in shenanigans. So what? Why bother? What have we gained, with all this effort, if we're back in the same old shit again?

The whole point was that we no longer needed to get anyone's permission to communicate, to publish, to build new services for interacting with each other; we could just _do it_. If federation is gone, then those days are gone, and the most important reason to care about the Internet is gone, too.

<comment><USER4> I hesitate to get all Clay Shirkey here, but I think this is fundamentally different from media conglomerates and Bell Systems, given that now anyone has the ability to build their own overlay service with relatively minimal investment.

Part of what I've been noticing is that we have these "walled gardens" today that people consider to be synonymous with "lock in," but it's actually easier for people to move from Viber to WhatsApp to Telegram to Signal today than it is for people to move from gmail to yahoo mail.

In a sense there's _less_ lock-in with centralized messaging services than there is with the federated ones, due in part to the move towards user-owned identifiers like phone numbers.

<comment><USER5> I get what you are saying about it being easier to move from one walled garden to another (based on the evidence that those moves happen more often than moves from between email providers)... but there is such a huge caveat that those moves are never a move chosen by an individual.

I cannot, as an individual, choose to move from one walled garden messenger app to another - if I do, I cannot message those people that don't. I am stuck going along with the group. This is ok in a lot cases (when the group's priorities line up with mine), but sometimes the things that are important to the group are different than the things that are important to me. For example, I might prioritize security over ease of use, but since the group doesn't, I will never get my wish, and I am stuck on a service that sacrifices security for ease of use.

<comment><USER6> Wouldn't you still have that problem with a federated system? You could roll your own uber-secure decentralized messaging protocol right now, if you wanted, but if nobody else adopts it then you're basically SOL.

<comment><USER7> The difference, I think, is that with federated system you can have a partial state where you communicate securely with those that have also adopted the security extensions, while making insecure connections with those who didn't, all within the same application/protocol (by using protocol extensions). Therefore, such features can be gradually adopted by an increasing amount of users.

If the system is centralized and it doesn't support security, it's all or nothing; to enable secure protocols, both you and the other party must change to a different app, and you'd have to support both systems in order to communicate with secure and insecure users.

</comment></comment></comment></comment></comment></comment><comment><USER8> In general I agree with @moxie's arguments, however I've come to to be wary at his condescending attitude and discontent towards people disagreeing with his choices.

Like there's a review on the Android Signal app complaining that it asks for too many permissions, and it does ask for an arm, a leg and your soul, with the reply being unprofessional imho. I understand that this is open-source, but if you publish it and want users, you need to act professional, otherwise it shouldn't be a surprise when people complain.

To the subject at hand, I strongly disagree.

Moxie says that email is frozen, being why it is unencrypted, blaming the lack of progress on it being federated. But you know, I'm willing to bet that in 10 years from now WhatsApp and Slack will be both dead, just like Yahoo Messenger and ICQ before them, while email and IRC will still be around.

And I think that email is unbeatable, because it is federated, because it's governed by standards and because in spite of all constraints, it's quite adaptable, being the kind of platform supporting short term proprietary solutions because (and not in spite of) its client/server decoupling.

Slack for us is just a long and one dimensional stream of greetings, jokes, warnings and meaningless blabbering. Email on the other hand is the archive of everything we do, being the Git of our interactions and the primary channel for knowledge dissemination.

Is it unencrypted? Sure, but it doesn't matter though. Because we are willingly trading that for a capable search engine and a good web interface. Trade secrets aren't communicated over email anyway.

I think Moxie is missing the point. He's emulating WhatsApp, but you can't beat WhatsApp at their own game. Did WhatsApp really deliver encryption to 1 billion users? Well, those are 1 billion users that probably won't use Signal or chat with Signal users. Oops.

<comment><USER9> I think you're really missing the point here.

> Moxie says that email is frozen, being why it is unencrypted, blaming the > lack of progress on it being federated. But you know, I'm willing to bet > that in 10 years from now WhatsApp and Slack will be both dead, just like > Yahoo Messenger and ICQ before them, while email and IRC will still be > around.

Yes, and email will still be unencrypted, while the WhatsApps and Slacks of the future will probably be encrypted end-to-end.

> And I think that email is unbeatable, because it is federated, because it's > governed by standards and because in spite of all constraints, it's quite > adaptable, being the kind of platform supporting short term proprietary > solutions because (and not in spite of) its client/server decoupling.

It's not adaptable enough to introduce meaningful encryption to it.

<comment><USER8> Slack isn't encrypted and it doesn't make sense to pretend that it is. Introducing encryption is actually difficult for them, since they rely on a web interface connecting to a central server.

But anyway, email can support encryption if you want it, not by one, but two protocols. Email is actually the main channel that journalists and businesses are using for communicating actual secrets over the wire. It's actually the only generally available " _meaningful_ " channel, because even with WhatsApp's encryption, you still can't fully trust a binary blob communicating with a proprietary server, not without the ability to do third-party reviews.

You can do S/MIME, which is encryption with certificates released by an authority (just like HTTPS), or you can do PGP/GPG which is more decentralized, putting the onus of establishing a chain of trust on you. S/MIME is supported out of the box in most email clients and setting up GPG in something like Thunderbird is actually not that hard: [https://support.mozilla.org/en-US/kb/digitally-signing- and-e...](https://support.mozilla.org/en-US/kb/digitally-signing-and- encrypting-messages) ; And even for web interfaces there's this browser extension called Mailvelope that's pretty cool: [https://www.mailvelope.com/](https://www.mailvelope.com/)

You see, email does support encryption, just not by default. And the reason for why encryption isn't popular with email is because _people don 't freaking care_.

And the often dreaded protocol that Moxie usually speaks against is XMPP. XMPP apparently isn't good for delivering push notifications on mobile phones, but it does supports easy to use encryption. It's called OTR: [http://wiki.xmpp.org/web/OTR](http://wiki.xmpp.org/web/OTR) ; Oh, and there are is of course an open-source Jabber / XMPP client for Android and it does support OTR, working quite well actually: [https://play.google.com/store/apps/details?id=eu.siacs.conve...](https://play.google.com/store/apps/details?id=eu.siacs.conversations)

You see, WhatsApp's progress is extraordinary, but only because of popularity, because they delivered encryption to people that don't care. Which is quite a feat, except that with another update they can also revert all of that, without users being able to do anything about it. And WhatsApp's progress is not extraordinary for its technical challenges.

<comment><USER9> > Slack isn't encrypted and it doesn't make sense to pretend that it is.

I didn't say it was.

> But anyway, email can support encryption if you want it, not by one, but two > protocols. Email is actually the main channel that journalists and > businesses are using for communicating actual secrets over the wire.

Yes, but they're using GPG over email. Another example of a nesting protocols approach are plugins that support OTR over XMPP. Nesting protocols is a valid approach for technical users, but the user experience is such that it will never catch on with non-technical users. And, in context, _providing e2e encryption that non-technical users will use_ is a big part of moxie's goals.

S/MIME can't be deployed meaningfully because major webmail providers will never support it; data-mining email is a huge part of their business model.

So no, email does not support encryption.

> And the reason for why encryption isn't popular with email is because people > don't freaking care.

Nobody cares about encryption in the abstract, but a great many people care about privacy. Many people who care about privacy simply don't have the technical knowledge to know what encryption they need and use it, and can't give up the communication that email/chat/etc give them. My dad, who has trouble bolding text in Word, learned how to use Signal because he cares about encryption.

</comment></comment></comment></comment><comment><USER10> Some relevant background information on this issue:

[https://github.com/LibreSignal/LibreSignal/issues/37](https://github.com/LibreSignal/LibreSignal/issues/37)

<comment><USER11> Interesting discussion.

<comment><USER12> I don't understand how Guardian were unable to obtain a license to use Signal/Axolotl in Chatsecure. The libraries on Github are GPL3, is there some missing IP I'm not aware of?

Also it saddens me that LibreSignal is effectively dead now, along with any future third-party clients. I think forking the Signal server and (later) adding federation could spark a community of free and secure messenger apps for the 21st century.

Even if that means starting with an empty user base. After all, most of my contacts with Signal only ever use it to contact me, it wouldn't be difficult to convince them to change app.

<comment><USER13> Apple imposes usage rules on software downloaded from the App Store. The GPL doesn't allow this, so Open Whisper Systems would have to offer different terms.

</comment></comment></comment></comment><comment><USER14> I would like to point to a very similar piece that was written about infrastructure for open science [0]. The basic argument is along similar lines, but adds another important wrinkle, which is that in federated systems centralization will eventually arise and often it will be controlled by people and organizations that the federated community do not trust and cannot control (Elsevier being the example in the scholarly world). It is often better to spend time building lasting open institutions that have principles that are in line with the values of the community and are federated at the social level rather than the technical level. Politics matters, and despite how much we might like to avoid it, sometimes we can use it to our advantage.

0\. [http://cameronneylon.net/blog/principles-for-open- scholarly-...](http://cameronneylon.net/blog/principles-for-open-scholarly- infrastructures/)

</comment><comment><USER3> That's one of the most depressing things I've read in a while. If this is actually true, the internet has failed.

</comment><comment><USER15> Just because it's not super simple doesn't mean we should treat federation as a dead end. Sandstorm is one way for non-admins to have their own server and there's work regarding self-hosting everything. It's unsexy, it's not a money maker like a centralized messenger, but unless we want to live in a world where there's only one or two centralized messaging solutions, we as developers have to eat our own dog food and improve easy hosting and federation.

<comment><USER4> How would apps running on Sandstorm avoid the problems with federation in today's world outlined in the blog post?

<comment><USER16> It looks to me like your article is really arguing for central control of the code, rather than central control of the serving infrastructure. Having everyone running the same code means changes can be made quickly because only one implementation needs to change. Centralized serving infrastructure makes central control of the code easy.

But if you look at mobile, we have central control of the code there without central control of the infrastructure: everyone has their own phone, yet runs the same apps that stay up-to-date via app stores.

Sandstorm is basically taking that model to servers: within 24 hours of an app update, everyone gets a notification and can click one button to update their copy, so everyone tends to stay up-to-date.

(Disclosure: I'm the lead developer of Sandstorm.)

<comment><USER17> > central control of the code

That's just an excuse to not implement backwards compatibility in the protocol. Central control is also a security risk, as we've seen recently with Apple and the FBI. If the code is controlled centrally, the FBI (or whomever) only has to strong-arm one target.

> gets a notification and can click one button to update their copy

That sounds like you're trying to keep the user in control, which is great. I haven't head of Sandstorm before, but it sounds interesting.

Have you considered the problem of forced updates? I'm not sure there is a good way to protect against the FBI trying something similar to the recent drama with Apple, where they order you to force a "special" update on {someone,everyone}.

<comment><USER16> There's certainly a trade-off here. I think that making updates as frictionless as possible is overall a big win for security and development velocity. The down side is, of course, that malicious updates take effect more quickly.

FWIW, Sandstorm is already designed to limit the possible damage from malicious apps in general, by making sure each app has only the minimum privileges it needs to do its job (and making sure the UX to grant said privileges is painless for the user). For example, we've seen quite a few security vulnerabilities in apps that were largely mitigated when running the app on Sandstorm:

[https://docs.sandstorm.io/en/latest/using/security-non- event...](https://docs.sandstorm.io/en/latest/using/security-non-events/)

Hypothetically, in the Sandstorm model, you could architect a messaging app which is incapable of leaking messages to a third party: for each contact, you would create a separate grain (fine-grained instance, in Sandstorm terminology) of the app, and you would permit that grain to communicate only with that contact's corresponding grain they created for you. If the app cannot communicate with other grains of itself -- much less third parties -- then it cannot leak any communications.

Obviously, there are a lot of UX questions raised by this design. It is a goal of the Sandstorm project to solve those UX issues, and we believe they are solvable, but I can't claim to have all the answers today. More likely what you'd run today is a single grain which can talk to all your contacts. In this case an evil app update could almost certainly find a way to covertly leak any message through the network of contacts.

(And, of course, another issue, if communications are crossing the internet, is traffic analysis and covert channels embedded therein.)

So, yeah, there may or may not be a good technical solution here. But on the bright side, the Apple-FBI case seems to indicate that the government doesn't have the power to compel false signatures on code updates. I can only hope that interpretation stands and is reinforced over time.

</comment></comment></comment></comment></comment><comment><USER18> I agree with Moxie's assertion: federated services are losing. As it stands they can't keep up with the rate of change and iteration currently offered by centralized protocols.

But rather than this being a problem with federation itself, perhaps it's an issue with existing implementations. Things like XMPP give protocols so much flexibility with extensions that upgrades become costly and difficult to implement. Others, like HTTP, SMTP, and IRC are updated very slowly.

It seems like it should be possible to implement federated protocols that are focussed on fast iterations. For example, a protocol could specify that each version has a fixed lifetime of just one month, and require all clients and servers update to the new release in the last week of that month. Such a fast- paced protocol would have some disadvantages over slower ones (e.g. longevity), but it seems better suited to the pace of modern software and service development.

But I've never developed a protocol, let alone a federated one. I'd love to hear some potential problems or examples of failed protocols that have taken this kind of approach.

</comment><comment><USER19> This is very confusing and the argument don't hold very much. It looks sadly more like a justification against making the effort, which he has a right to not want to attempt, but doesn't make sense.

The real issue is how can we have an open governance model that moves protocol forward a lot faster and it seems that with a little imagination we could tackle most of the pain points. So maybe we should fix the infrastructure instead of celebrating silos that don't talk to each other even when using the same protocols?

</comment><comment><USER20> > An open source infrastructure for a centralized network now provides almost > the same level of control as federated protocols, without giving up the > ability to adapt.

That's simply not true. Unless you're Google/Facebook/Apple/Amazon, you'll be unable to get anyone to use your centralized network. Which makes it worse than useless. "Build it and they will come" doesn't work in a world of walled gardens, curated content and censorship.

</comment><comment><USER21> I think I read this in The Mythical Man Month but writing from memory: Every software development project, no matter how well executed will produce outdated software. Said differently any software that is used is by definition outdated. This is simply, because unknown unknowns only become known unknowns during development.

Bitcoin is a perfect example of this. It might stick around for a while mainly because so many people are already invested in it, but when it comes to features Ethereum runs circles around Bitcoin. On the other hand Ethereum will probably never be fully finished.

<comment><USER22> Well, Ethereum features a turing complete scripting system and a ton of tools to make use of it, but it doesn't solve Bitcoins most serious problems, and is in fact worse off for most of them.

Miner centralization is a huge problem for Bitcoin. The fact that 11 entities control >90% of the hashrate, and that 2 control >50% of the hashrate is a huge issue for Bitcoin. The pressures we understand to be causing this are more significant in Ethereum at scale. Ethereum is not even at scale and already is doing worse than Bitcoin in terms of hashrate centralization.

Ethereum also has significant scalability problems. Bitcoin struggles to hit 4 transactions per second, and every transaction on Ethereum is substantially heavier per transaction than Bitcoin. That scripting system is not free, and already Ethereum is 20% as heavy as Bitcoin despite being 1/5th the age and having 1/10th the usage. And that's before the fancy apps like Augur have gained traction. Augur is significantly heavier than anything running today, and it's definitely not the heaviest app that people have gotten excited about.

And the development is almost fully centralized. The current state of Ethereum is that what Vitalik says is what will happen, and while there are people who could shut him down... they won't. At least not in the near future. Ethereum has already performed hardforks and has several more planned.

I agree that Bitcoin has taught us a lot of lessons that have paved the way for its obsolecense. But I don't think that Ethereum learned them, and I think that Ethereum will seem a lot less attractive after it has to deal with demand matching what is currently demanded from Bitcoin.

I would almost go as far as saying they are orthogonal products. Bitcoin, above all else, prioritizes decentralization. Ethereum prioritizes features and flexibility, at the cost of scalability and centralization.

</comment></comment><comment><USER23> > As a software developer, I envy writers, musicians, and filmmakers. Unlike > software, when they create something, it is really done — forever. A > recorded album can be just the same 20 years later, but software has to > change.

This is funny, a few lawyers I know, constantly complain they should have got into software.. Write once, sell many (pre-SaaS days..). They complain in their job, every day they have to go out and perform to continue to earn. Just funny how we ALL think the grass is greener on the other side (and tend to oversimplify).

</comment><comment><USER24> I totally get this; federation is _hard_ , and its so much easier and nicer ─ as a developer ─ to have a centralised service. Often centralisation is the right choice for a particular project, and I respect that.

That doesn't mean we should give up trying to federate things, though. The major upside (for me) to federated systems is simple: _choice_. Choice over the client you use. Choice over the servers you use. Choice. For something so fundamental as how we communicate over the internet that's incredibly important. I want to be able to use the app I want without having to figure out if the other person is using the same app, and i don't want to have to have 10 different apps on my phone just to keep in touch with everyone.

The reason I think that things like email and SMS are still so prevalent is how you don't need to care what service the other people are on, you don't need to worry about how other people are going to talk to you, it all just works. It's true that currently a lot of the email traffic is going through google, that sucks, _but_ :

\- If google discontinues gmail then _your_ email still works, people can still talk to you. It's annoying you need to get the new addresses for all your contacts that used to use gmail, but that will get resolved quickly enough.

\- A day may very well come where people decide another service is better, but then people are free to move there without having to try and convince all their friends and family to also switch. (Take browsers, for example, the browser that _everyone_ uses to access the internet changes over time. And its great! People use what they want to use, the servers don't care, everything _just works_ ─ well, more or less).

Not _everything_ needs to be federated, often there are situations where its advantageous for there to be a central authority. (The blog post highlights a few of those situations). That's also great! People who want those things are then free to choose to use those things as well. Using 2 apps you want to use is still better than 10 you don't want to use.

Federation is hard, and it imposes constraints, but I really, really hope that we can build something that works before we give up and hand over all our comms to a particular company.

This is _exactly_ why I work at matrix.org; I just want to be able to use the clients I want without having to care what everyone else uses. I don't even have to care if matrix.org goes down (except the fact I have to fix it), I can happily talk to other people since I connect via my own server.

I do actually agree with a lot of what's said, I just disagree with the conclusion. Federation iss hard, but it's just so worth it if we can get right.

<comment><USER25> > The major upside (for me) to federated systems is simple: choice. Choice > over the client you use. Choice over the servers you use. Choice. For > something so fundamental as how we communicate over the internet that's > incredibly important. I want to be able to use the app I want without having > to figure out if the other person is using the same app, and i don't want to > have to have 10 different apps on my phone just to keep in touch with > everyone.

Isn't that exactly the point of the post? If you have lots of choices, what you end up using depends on the intersection of features that your client and the client of the person you communicate with can handle. Which usually ends up advancing slowly, if at all. I'm still a user of XMPP and maybe there is a way to do video chats. But I don't bother trying to set that up as I don't expect it to ever work reliably: I just checked five random contacts and everyone of them uses a different jabber client. So what I end up doing is using XMPP for text chat on my desktop machine and skype/hangout if I need video conferencing.

Same with email. Apart from a bunch of anti spam headers, emails I receive basically look the same they did 10 or 20 years ago. Trying to implement accessible end-to-end crypto probably won't happen for the same reasons.

<comment><USER26> And yet the Matrix team is doing it _remarkably_ well.

I've been a user of Matrix for going on a year now, and they continue to roll out updates and improvements, over ALL of their platforms -- I use the android, iPad, and desktop/web apps every single day. They're also a federated service. Several of my friends run their own servers.

Some days there's a little bar across the top of my page on the desktop client that says "refresh to update your experience!" and I do. My experience updates. Everything continues to work.

Matrix has done such a good job making it easy to roll out updates that people... do.

And I can't tell you how thrilled I am to be living in a federated world. You just can't compare this to e.g. Slack. I can get friends from all backgrounds on the same system because it's so open.

The Matrix team is proof by example that federation and rapid forward motion _is_ possible.

</comment></comment></comment><comment><USER27> Are we super sure about this premise: a vendor builds a centralized solution on top of (or evolved from) a federated protocol in order to be able to adapt with speed to a moving environment?

For instance, I am not so sure that is the reason Whatsapp built a custom XMPP.

I am more inclined to think that decentralized-anything is basically impossible to monetize so companies thinking for-profit will always chose the centralized walled garden.

<comment><USER4> I'm writing from the perspective of Signal, which is not a business, so it's definitely not about monetizing users for us.

<comment><USER28> It would be interesting to know how you do see Signal, then.

After reading your comments on the LibreSignal tracker, my impression was that you are very much writing with your business hat on, as you are framing alternative clients as "products" and trying to protect the Signal brand, as well as preventing third-party clients from using your service - all typical business moves.

I can see how federation breaks the phone-number-based identity and discoverability, so I accept your position in that regard.

However, opening up the service to community-developed clients would be A Good Thing. You have to maintain backward compatibility to a certain degree for the official client anyway. If community clients fail to roll out a new protocol version, it will be a valid move to lock them out together with outdated official installations. You wrote that maintaining servers is difficult, but I am sure that it is possible to find a scheme where your additional financial burden of accepting (but not providing support for) third-party clients is compensated for.

</comment></comment></comment><comment><USER29> The term "federation" has been overused, misused and abused. At it's base layer, Federation can be thought of as process that unifies things and the people using the things in a way that is reproducible at a future date. Within the context of the Internet and Software (the cloud), Federation _should_ mean "federated use of computer resources" and extend the three primitives of the cloud to be used by all, at will:

1\. Compute - allows the transformation of one type of data to another.

2\. Storage - allows the storage of data.

3\. Network - allows the transfer of data from compute to storage, or vice versa.

Federation's historic constituents have been standards, payments and identity. In order for cloud federation to be viable, the primitives above must be able to be used in a way that allows some type of "standardized trust" to be applied, some type of identity to be associated with it, and some way of paying for the resources used.

One possible solution for implementing a Federated Cloud of Clouds is to use cryptocurrencies to pay for the processing of data, identify who's data it might be, and then encapsulate the data being federated into some type of standard. I have explored a generalized solution for this and have presented it to a few peers. It seems doable, if we can mobilize the development community's intent to change how software is written.

BTW, I don't consider "standards" to be anything other than a light consensus mechanism applied to a set of data which is then made immutable. One might consider a blockchain a "standard" by the evidence it is unchanging, once created.

Federation will only occur once we've moved infrastructure to using cryptocurrencies for deployments. It will also require a radical shift in the way we think about how software is written and paid for.

</comment><comment><USER30> No users, no walled garden. More users, more walled garden. Is this just the natural state of systems that require/acquire network effects?

<comment><USER31> I have a universal theory about this which is "spam and abuse make everything suck".

This is why we can't have an open libertarian Internet, and instead have walled gardens and moderated forums - ordinary users don't want to deal with the crap.

It's also why we don't have open API's, and why the API's that the big providers do give us tend to be nerfed and then discontinued - they're constantly abused, which imposes a maintenance cost that businesses have to justify.

It's why an email server is so difficult to run and email delivery is so unreliable. It's why you can't (or shouldn't) rely too much on Paypal. It's why governments effectively outsource Internet policing to big providers.

And so on.

</comment></comment><comment><USER32> Nonsense, the www is not stuck in the 90's. Browsers adapt, compete and innovate. And err http is at 2.0. The fact that gopher didn't kick off does not rubbish the idea of common protocols in the first place.

<comment><USER33> HTTP is used for far more than just browsers. how broad is the current adoption of HTTP 2.0? Will there ever be a time when all HTTP clients, servers, proxies, etc will have upgraded to 2.0 - clearly that's never going to happen in the foreseeable future so we're stuck in a mishmash of supporting HTTP 1.x and HTTP 2.x clients and server software indefinitely - similar to XMPP extensions the article refers to. It's obviously much faster to innovate and update all clients when you have control over a centralized network and auto-updating clients.

<comment><USER4> What's more, HTTP's recent movement is arguably only because the web experience has centralized so much around Google.

Google already had the top two most popular websites in the world, so once Google Chrome also became the most popular web client, it was easy for them to develop a new communication protocol of their own, which everyone else has more or less begrudgingly agreed to call HTTP/2 and start deploying as well.

<comment><USER34> Google did not write the HTTP/2 spec.

While Roberto Peon is one of the authors (and a core developer of the preceding SPDY protocol) saying that HTTP/2 is some Google invention is a bit of a punch in the face to the IETF and the two other authors who do not work at Google.

</comment></comment></comment></comment><comment><USER35> I'm largely sympathetic to Moxie's core arguments, and to the extent that I disagree, it's his prerogative to do what he thinks is best with his project.

I will point out that some people are using "federated" and "decentralized" as synonyms, when they are distinct concepts. The Tor network, for example, is decentralized, but not federated. You can run your own Tor node, but that node has to be accepted by the directory authorities in order to become a part of the network. You could conceivably set up your own Tor network, with your own directory authorities, but of course you can also create your own alternative network with Signal, since both the client and server code are free software.

Ricochet, the messenger that uses client-side Tor hidden services to create server-less chat, is also decentralized, but not federated. Ricochet clients talk to other Ricochet clients. There is not IETF RFC out there for Tor or Ricochet, that you can use to build your own implementation and federate into the network.

Moxie's claim that federation inevitably leads to moribund cruft may be over- stated; after all, http is not exactly in trouble. Nevertheless, I think that it's probably true that maintaining a federated protocol that is also an easy, seamless, user-facing piece of software is most likely a tall order.

</comment><comment><USER36> I think his view on the address book as your personal social graph is interesting. Because this has been mainly discussed as privacy violation because it involves uploading the address book to a server to check for in- network users.

But it has also another side and sadly this side as an independent social graph is mostly ignored, at least in Germany.

How is this being discussed in other places? I had this discussion when WhatsApp turned on full end to end encryption.

</comment><comment><USER37> So: I was the other side of the email conversation that Moxie alludes to in this post, so I'll respond to it here given comments are disabled on the OWS blog :)

1\. Totally agreed that federation slows down evolution of the core protocol. However, higher level protocols do _NOT_ have to be stuck in time forever in the manner of SMTP if you design them with a migration/evolution strategy from the outset. For instance, with Matrix.org the core premise is decentralising communication between different networks. _This includes different versions of Matrix itself_. We could build an entirely new Matrix 2.0 tomorrow, using (say) a fully p2p WebRTC Datachannel transport or IPFS or whatever rather than today's HTTP APIs... and simply bridge it into the existing Matrix network using Matrix's existing bridging architecture. In fact, one of our favourite thought experiments is the process of how to evolve Matrix into a full e2e-and-metadata-privacy-protecting protocol at some point in future - as per [http://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20En...](http://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20Entropique.pdf). How you protect metadata privacy if locked to a single centralised service like Signal is perhaps questionable.

We believe that avoiding being dependent on any single communication provider is just as important to user freedom as maintaining communication privacy. If I don't trust Signal to host my communication reliably, I want to pick my own provider... whilst still being able to talk to other Signal users.

One could argue that end-to-end encryption is incompatible with federation, as if a vulnerability is found in the encryption ratchet you need the power to upgrade the world 'instantly', as WhatsApp or whoever can. However, I am not convinced this is a showstopper. It's certainly convenient that WhatsApp can instantly lock out all versions of an app which are known to contain a vulnerability from their network, but you can get a similar effect by issuing a press release as per heardbleed, poodle etc; giving users a way to check if they're vulnerable; encouraging them to move to a provider or app which is _not_ vulnerable. It's not watertight, but it's a compromise I think many would be willing to make in exchange for having the freedom to select their communication provider and communicate with who they choose.

2\. If the federated protocol has well-defined layers, it's not even a problem if the lower layers are slow and hard to evolve; you just go and swap out the higher layer ones. Internet Protocol is so widely deployed it's infamously painful to evolve... but it's a relatively simple and well-focused problem domain, so a huge migration like ipv4->ipv6 happens very rarely. But it hasn't materially slowed down the adoption and uptake of the internet - in fact, ipv4 is a victim of its own success! Meanwhile, HTTP is also so widely deployed that it's a relatively slow process to do something like HTTP/1.x->HTTP/2\. But, again, it turns out this isn't remotely a showstopping problem - most of the interesting stuff happens layered as applications _on top_ of HTTP - <USER2> does one thing, and does it relatively well, so it's a great building block. And it's the basis of the _entirely open and interoperable_ architecture of the web.

With Matrix, we're trying to provide a similarly simple and focused base layer: a decentralised pubsub/storage API layered on HTTP. We provide some modules that define additional semantics (messaging, VoIP etc) as layers on top of that core API ([http://matrix.org/docs/spec/client_server/r0.1.0.html#module...](http://matrix.org/docs/spec/client_server/r0.1.0.html#modules)) which can evolve separately.

We believe that having an open and interoperable protocol for securely synchronising data in realtime is as fundamental as the web itself, and this is _NOT_ a function that should be silo'd into any provider.

3\. The blog post says: "One of the controversial things we did with Signal early on was to build it as an unfederated service.". This seems a bit strange, given the TextSecure server itself exposes a basic federation API: [https://github.com/WhisperSystems/TextSecure- Server/tree/mas...](https://github.com/WhisperSystems/TextSecure- Server/tree/master/src/main/java/org/whispersystems/textsecuregcm/federation)

4\. My actual retort wasn't to tell Moxie that he's dumb - he's obviously an incredibly smart guy, even if I disagree with his position here. I actually said: "Okay. The internet wouldn't have got very far without interoperable application-layer protocols defined by 3rd parties, but if you would only ever consider using one for TextSecure that you invented yourself, that's your call :)"

So, if anyone's reading this and still believes in the dream of an interoperable and federated internet, feel free to come hang out at [https://matrix.to/#/#matrix:matrix.org](https://matrix.to/#/#matrix:matrix.org) and live the dream :)

<comment><USER20> > If I don't trust Signal to host my communication reliably, I want to pick my > own provider... whilst still being able to talk to other Signal users.

I couldn't agree more. And it's not just a matter of trusting the host. It's a matter of trusting and liking the clients. If e-mail were hotmail only, I'd hate it. But it's not. E-mail is thousands of clients on dozens of operating systems, which can _all_ talk to each other. Signal, hah, it doesn't even work on my phone, and there aren't even dozens of phone operating systems out there.

</comment></comment><comment><USER38> Moxie: there's a third alternative to centralization and federation which nobody is talking about on this thread: P2P. I'd be interested to hear your thoughts on what pitfalls someone (me) might encounter trying to implement a peer-based messaging system. I've got a lot of learning to do before I feel qualified to actually write code for such a project, but it's something I'm actively working toward.

<comment><USER39> If federation is too hard then I don't think P2P, which is even harder, will be considered.

<comment><USER38> It's harder to deploy updatable encryption on a federated protocol than a centralized one, but as I see it, the difficulties are social rather than technical. Deploying updatable, usable encryption on P2P is technically more difficult than on federation or centralization, but I'm not convinced it's socially more difficult.

The core problem of updating federated systems is that big players can choose not to play. If Google or Yahoo decide not to support a change to email, the change is dead in the water. This isn't just hard, it's intractable.

But with P2P systems, non-reliance on peers doing anything in particular is built-in. For example, peers that don't support a change limit the size of the swarm you can peer with, but they don't inherently break the feature as long as there are some peers who support the change. Many Bittorrent clients support encryption and many don't, many bitcoin miners support alternate protocols to speed up pooled mining, and many don't.

I don't know what the implications of this would be for a system like Signal. It maybe that it doesn't solve anything; I'm just not ready to conclude that for myself yet and I'd be interested to hear Moxie's take.

</comment></comment></comment><comment><USER40> Let me summarize. "We want to make sure we make money."

Let's burn these star networks!

</comment><comment><USER41> IMO you can still add federation (and you should for freedom and security), but no need to expose it to the user. For example: set the default server to signal servers. For sake of sanity, you probably want to route all servers to the default signal server. But you could easily allow user@server. If you can figure out how to use phone numbers directly between servers, congratulations, cause it will not be easy. But I think people who want to run their own server will not find that much of an issue.

In terms of getting stuck in time, you could use though love, and require backwards compatibility for like a month but no-longer. But so long as you keep the phone-numbers @the signal servers, your server will be the reference, and any server not following will get the blame.

</comment><comment><USER42> _what Facebook did with email_

What did Facebook do with email?

<comment><USER20> Bloody murder, basically.

Whenever I try to communicate with someone under 30, e-mail is simply not an option. A Facebook message is often the only way (or worse).

</comment></comment><comment><USER26> There's a sort of resignation about the tone here, both in the article and the comments, which is very depressing.

Let's take that punch, roll with it, and redirect its energy. If centralized efforts, much like BDFLs, are looking like a good option for development cycles, okay. How can we wield that knowledge, but also build lifecycles _around_ it that can help us buy back the powers and critical freedoms of federated systems?

</comment><comment><USER43> Every security engineer I have met so far is to some extent (some of the to quite an extent) paranoid and control-freak. That's good for security engineers, you want them to be paranoid and control freaks. Of course, the bad part is that they are paranoid and control-freaks.

So, although I don't question huge amount of work brought to the public for free by Moxie, I cannot notice that he killed all points of federation (even those which were to some extent under his control, [http://www.cyanogenmod.org/blog/whisperpush-end-of- life](http://www.cyanogenmod.org/blog/whisperpush-end-of-life)), that he sabotages non-Google-controlled repositories ([https://github.com/WhisperSystems/Signal- Android/issues/127](https://github.com/WhisperSystems/Signal- Android/issues/127)) of his so called open software client. I don't care that much because for this and other reasons I won't touch Signal with a ten-feet pole, and federated alternatives (XMPP) work for me just fine, thank you. So, my suspicion is that instead of some theoretical difficulties the issue is that he got how own fiefdom under his control, and now he is not willing to let it go.

All these opponents of federation and open software (I am not talking about just FLOSS here, I mean truly community-drive software), each with their fiefdoms to protect, argue that we are stuck with the open technologies from 1990s (or even earlier), and only their proprietary silo (proprietary meaning with only one implementation and under their control) is able to bring us a shiny new blink. However, they tend to ignore the other part of the story. The biggest problem of storing my life in proprietary silos is not that they are under control, I don't live a life in delusion of importance, so I don't expect anybody to mine my communication with my wife about what to do for dinner (and yet, even that communication is encrypted by a pretty good encryption system, which works just fine with a plain XMPP). The biggest problem is that every individual proprietary silos in the moment owner of such silo goes out of business, or for some other reasons looses interest in providing the service. So, the question is not how many technologies from 1990s we use, but how many proprietary technologies from 1990s we don't use. Yes, I have stored on my hard drive all emails since 1997, because old boring mbox files still work as they did. But all those exciting and sometimes tearful conversations I had on Yahoo! IM or ICQ are gone forever. That bigfoot.com and mail.com accounts I had for my life? Yeah.

And to the second lie Moxies lies to himself (I am willing to believe he really means it). It is suddenly easy to move between proprietary silos? Yeah. It is lovely that we have to keep unique identifier (phone number) for all NSAs to trace us in some weird databases somewhere (that livejournal.com account? yes, it is now owned by the Russian Коммерса́нтъ; yes, I know that this newspaper is not that bad). And yes, it is seriously interesting if perhaps phone numbers would serve as the unique personal identifier most Americans were so afraid to introduce. A possibility to have anonymous accounts? Yeah.

However, even this does not seem to make transfer between platforms that easy. If all your friends are on Telegram, then no matter how easy _for whole group_ it would be easy to transfer, you cannot transfer unless whole group does. How many people really and truly love Twitter, and how many of those who hate it with passion are able to move to some better platform? Nobody, because that is where people are.

</comment><comment><USER44> Perhaps the "federation" that should evolve is not federation of the servers behind a single protocol or app, but federation between multiple apps. Applying the traditional definition of "federation" to Signal implies that any entity could host a Signal server, and any Signal client could talk to that server. Moxie mentions the main issue with this, namely that because of the "evolving ecosystem," it's impossible to keep all servers using the same protocol. Also consider that _trust_ is another significant issue -- can you trust the operator of the Signal server you're connecting to? Can you trust not only that the server software is up to date, but also that no malicious actor has modified it?

Because of these trust issues, the benefits of federation for users are unclear. Why connect to some random Signal server if you feel safer connecting to the official servers?

If the answer to that question is, "because I can connect to _my own_ Signal server, so I don't need to trust _anyone_ ," then I posit this question: Do you need permission to build a federated service? Is it possible that federation can evolve without any central planning or permission to do so?

Consider the "messenger wars" of the early 2000s. There was no official "federation" of messaging services, and yet, people built clients that could interoperate with all of them. In fact, Microsoft itself wrote a client that was interoperable with AIM. [0]

Why can't the same sort of "grassroots federation" evolve within the current ecosystem of chat apps? If somebody reverse engineers the whatsapp protocol and builds a "whatsapp server," then modifies the whatsapp binary to talk to it (perhaps using something like theos-jailed [1]) instead of the official servers, isn't that effectively accomplishing unsanctioned federation? Along the same lines, is there anything stopping somebody from reverse engineering Signal to talk to Whatsapp, and vice versa?

The "walled gardens" have made it harder to reverse engineer binaries and protocols, but there is no fundamental impediment to achieving cross-messenger interoperability. If developers are motivated enough to build third party clients, it will always be possible, although the requisite reverse engineering effort grows more complex with every release.

[0] [https://nplusonemag.com/issue-19/essays/chat- wars/](https://nplusonemag.com/issue-19/essays/chat-wars/)

[1] [https://github.com/BishopFox/theos- jailed](https://github.com/BishopFox/theos-jailed)

<comment><USER43> See [http://spectrum.im/](http://spectrum.im/) with [https://github.com/davidgfnet/whatsapp- purple](https://github.com/davidgfnet/whatsapp-purple) (or use it with pidgin/adium/finch directly).</comment></comment>


Sslip.io: A Valid SSL Certificate for Every IP Address - <AUTHOR> http://blog.pivotal.io/labs/labs/sslip-io-a-valid-ssl-certificate-for-every-ip-address <comment><USER2> So, these guys bought a COMODO wildcard certificate and then stuck it (public and PRIVATE parts) on Github for anyone to download.

Wonder how long before COMODO revokes this cert?

If you have a test domain you can stick it on CloudFlare and get a certificate for free without the private part becoming public.

<comment><USER3> Yes, but the CloudFlare/server leg is unencrypted.

<comment><USER2> We give customers a certificate signed against our CA to secure the CloudFlare to origin server connection.

<comment><USER4> You do? Last I checked, I just saw that you had the option to put a self- signed cert on your own server, but no way to tell CloudFlare to validate it (e.g.: I couldn't upload my public cert to CF and say "this is what you should expect"). Alternatively, I could buy my own valid cert and put it on the server. Is the option to get a valid signed cert from CF new?

<comment><USER2> [https://blog.cloudflare.com/universal-ssl-encryption-all- the...](https://blog.cloudflare.com/universal-ssl-encryption-all-the-way-to- the-origin-for-free/)

<comment><USER5> Did this actually come out?

I've never seen the option in the panel for this, and as far as I know only a handful of users got accepted into the 'beta'.

</comment></comment></comment></comment></comment></comment><comment><USER6> > RAM is not stressed: of the 1015MiB of RAM, 182MiB are free, and only 6MiB > of swap is used. We typically don't worry about RAM on Linux systems until > the swap space used exceeds twice the physical RAM

That's a bad metric. The question is rarely "does this machine use too much swap". The problem comes when performance is degraded because pages that were evicted out to disk are now needed again, and those processes wait for I/O. swapin and swapout are the relevant figures.

edit: (If you're only using 6M of swap, it doesn't really matter, of course. But if a system uses any substantial amount of swap, you want to check rate, not quantity.)

<comment><USER7> Yes, that is quite a strange recommendation and the recommendation of "until the swap space used exceeds twice the physical RAM" is really crazy. The best recommendation for production servers is to disable your swap/page file completely then just let your entire system crash on OOM.

Often times it's better to have a dead system (you do have HA and auto- failover, right?) than to let difficult-to-track-down "slowness" into real time systems.

<comment><USER8> If your failover doesn't take extreme slowdowns into account, you've still screwed up.

It's more complicated than just turning off swap. Even without swap, when you run extremely low on memory the page cache will be squeezed to nothing and you'll thrash. And I don't think there's a way to set a minimum page cache on Linux.

So in other words, I would not rely on the OOM killer ever kicking in.

In a situation with more memory use over time a small swap can act as a canary, letting you know you're nearing a performance drop, while a swapless server could suddenly hit a molasses wall without dying.

<comment><USER9> Thrashing the page cache is typically _much_ less horrible than swap thrashing, so swap off is still an improvement.

If you want a canary, why not just directly monitor the page cache size?

<comment><USER8> I suppose it depends how big your binaries are, but once those are getting culled from memory things are not pretty.

Keep in mind that if your swap is not huge, it will very often fill will cold data and you won't have swap thrashing despite running out of memory.

Good point about measuring the page cache directly.

<comment><USER9> Ah yes. We can agree that both small swap and no swap are superior to the "2x RAM" nonsense that still pops up as a recommendation though.

</comment></comment></comment></comment></comment></comment><comment><USER10> While I despise the SSL cartel, there are many problems with this attempt at a solution.

Let's Encrypt began testing their free SSL certificates this week and will formally launch November 16th (two months from now)

[https://letsencrypt.org/2015/08/07/updated-lets-encrypt- laun...](https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch- schedule.html)

However they have no plans for wildcards and you have to renew every 90 days (automation possible).

They also do not have their intermediate certificate working yet (but will have to by November).

But if you do not need wildcards, the StartSSL free certificate has been an option for a long time:

[http://www.startssl.com/?app=33](http://www.startssl.com/?app=33)

(startssl works in all browsers and has a 1 year renewal)

<comment><USER11> WoSign issue free certs with up to 100 altnames, which is almost as good as a wildcard cert for many purposes, valid for up to 3 years. They also revoke for free.

They're the best option at the moment if, like me, you don't want want to put a penny in to the CA industry.

<comment><USER4> I was not aware of this option. However, it seems to be operating out of China. How does that affect security and availability in the long run?

<comment><USER12> It doesn't affect security, they're already in browsers' trust stores. It does affect availability, but only because (the last time I checked) WoSign's OCSP responders operated from China only. To address network latency issues with your users located far away, make sure you have OCSP stapling configured on your servers.

</comment></comment></comment></comment><comment><USER13> From what I can see this uses the same public/private key for everyone using the service. So it would be easy to MITM any HTTPS connection using this if you're a network admin or hostile WiFi etc.

I don't think this is a problem for the intended audience - developers and test sites.

But there should perhaps be a clear warning somewhere about not using this in production.

EDIT: Turns out this is actually mentioned on the FAQ page of [https://sslip.io/](https://sslip.io/)

<comment><USER14> I'm not suggesting that this makes it acceptable to use in production - but am I right in thinking that you'd be unable to MITM the connection if the server/client both support perfect forward secrecy?

<comment><USER15> Someone that intercepts the traffic act as a proxy and will just PFS with the client and the server.

Confidentiality should be ensured by PFS if the attacker is only sniffing. But so many scenarios where even an unsophisticaded attacker can do more that is is not worth thinking about.

<comment><USER14> That makes perfect sense - thanks.

</comment></comment></comment></comment><comment><USER16> It should have NOT SECURE written in big red letters - everyone has your private key, so there is no security at all.

<comment><USER17> It's very clearly stated on the project's website:

"sslip.io's primary purpose is to assist developers who need to test against valid SSL certs, not to safeguard content."

"Although there's no technical reason why you couldn't use the sslip.io SSL key and certificate for your commerce web, we strongly recommend against it: the key is publicly available; your traffic isn't secure."

<comment><USER18> I wonder what that scenario even is, where you need a trusted certificate and are also (for some reason?) unable to use the mechanisms widely available in environments (either OS or language/API) to trust a testing certificate.

This seems like a very silly service to operate, and as remarked by others, I guess the certificate will be revoked soon because the private key data is out there.

Mostly surprised that this wasn't obvious to a company like Pivotal from the first moment.

</comment></comment></comment><comment><USER17> Because people seem to be missing it, here's a quote from the project website:

"sslip.io's primary purpose is to assist developers who need to test against valid SSL certs, not to safeguard content."

<comment><USER19> I don't think they're missing it. It's a bad idea and you can have your own valid certificate for free from many companies. Or for test, you can create your own cert in 2 lines of bash. (and add the ca to trusted store, so it's just as valid as this one)

For testing purposes you can also generate your certs valid only for a few hours/days, so you can be sure they never get used in production by accident. And with proper SAN entries.

<comment><USER20> Exactly - there's no need for a service like this when you can have self- signed certificates. Create a CA cert to distribute across your team, then use it to sign host, wildcard and SAN certs as needed. If you need to share your site with people who don't have your CA cert, it's time to get a real one.

In case it helps anyone, I wrote an openssl wrapper with a simple syntax to manage self-signed CAs: [https://github.com/radiac/caman](https://github.com/radiac/caman)

</comment></comment></comment><comment><USER21> I've tried to find this info multiple times but what cert will work for:

domain.com

sub1.domain.com

sub2.sub1.domain.com

I'd love to buy one cert for my main domain and then be able to secure "infinite" depth of subs but every place I've contacted said that doesn't work yet they seem to have done just that...

<comment><USER22> There's a section in the article about how they use dashes instead of dots to separate octals in the IP. That way the wildcard cert covers those subdomains because they are only one level deep.

<comment><USER21> Ahh, I'm an idiot. Thank you for pointing that out to me. xip.io uses dots and so my brain just assumed dots on this one was well. I still would be very interested in finding a provider that did this or gave a reasonable number of domains on the cert. Though wildcard on subs is what I really want without having to buy one for each sub so I can do:

 _.server1.joshstrange.com

_.server2.joshstrange.com

etc...

<comment><USER23> Providers _can 't_ do this, because browsers implement an RFC that doesn't allow multi-level wildcards.

<comment><USER21> Yeah, I've read this previously. It seems odd to me, I feel like I _should_ be able to do this, I own the domain and I want to secure everything underneath it... _sigh_ I guess I'll have to settle for a cert that allows for lots of domains under it and just have to create a different cert for each domain.

</comment></comment></comment></comment></comment><comment> PC-Hawk That didnt take long...

Secure Connection Failed An error occurred during a connection to 52-0-56-137.sslip.io.

Peer's Certificate has been revoked.

</comment><comment><USER24> How about an IP address for every person?

<comment><USER25> you mean IPv6?

<comment><USER26> More like 1 IP for every atom in the universe.

<comment><USER27> I got curious... looks like we need IPv8 for that... estimates put it around 10^78, so 2^256 wont even do.

</comment></comment></comment></comment><comment><USER28> Nice hack, but:

What's preventing them from resolving _YOUR-IP.sslip.io_ to a completely different IP address that delivers some malware to you?

EDIT: Changed "your users" to "you"

<comment><USER29> because you shouldn't have users on this

<comment><USER28> (See EDIT) Okay, so what's preventing them from develivering strange stuff to you, that claims to be your test site, but isn't?

</comment></comment></comment><comment><USER30> Cert has been revoked

</comment><comment><USER31> Further evidence that the SSL/TLS model of combining transport security and trust is broken.

</comment><comment><USER32> sslip.io wildcard SSL certificate has been revoked!

[http://i.imgur.com/IyYEJNm.png](http://i.imgur.com/IyYEJNm.png)

</comment><comment><USER33> Just a heads up, @BrianCunnie, you are dead. I'm not sure why. I don't see anything in the comment history to justify shadowbanning, maybe someone with more insight into how and why people are banned can elaborate. Sorry this is top-level, you can't directly reply to dead comments.

<comment><USER34> Thanks mini. I'm not sure why they banned me (I used a link in my first post?), but they let me create another account, and am now using that one.

<comment><USER35> Not banned; your new accounts set off a spam filter. Sorry. We marked them both legit and restored all the comments. Should be fixed now.

</comment></comment></comment><comment><USER36> How about convincing the big browser vendors (e.g. through their bugtrackers) to finally accept CACerts without warning? Such a shame that.

</comment><comment><USER37> As you can probably tell, Comodo revoked our certificate this morning.

For those interested in rolling your own, we recommend getting your own wildcard certificate and deploying your nameservers: [https://github.com/cloudfoundry-community/xip- release#deploy...](https://github.com/cloudfoundry-community/xip- release#deploying-a-custom-version-of-xip-to-amazon-aws)

In the interim, we plan to see if there's a way we can accomplish what we want without violating the terms of agreement.

Thanks for the interest,</comment>


50 Top Startups from 2014 - <AUTHOR>

This is in response to "50 Top Startups from 2010 Acquired, Pivoted or Still Going?"<p>What are the top 50 startups of today? <comment><USER2> What makes a start-up "top"?</comment>


And the Smartest Site on the Internet Is... - <AUTHOR> http://www.technologyreview.com/blog/mimssbits/26150/?p1=A4 <comment><USER2> I think it's a little disingenuous, or perhaps naive, to say that Wired (for example) is faring "worse" because it has a disproportionately high amount of "Intermediate"-level material. I opine that Wired's distribution of Basic/Intermediate/Advanced material is likely _exactly_ where they intend it to be.

</comment><comment><USER3> Of course, IEEE is going to pack as much meaning and domain terminology as possible because they are talking to a limited audience that speaks their language. Yet those same technical papers could be unpacked and broken down for a wider audience by using laymen terms. It doesn't mean IEEE has smarter people; It just means they speak that vocabulary.

</comment><comment><AUTHOR> The results in the article are slightly skewed. They are presented with a "space" between "site:" and "domain". For example, "site: plos.org" has advanced at 86% and "site:plos.org" has advanced at 71%. It looks like the difference is the "spaced" form is doing a document term search and the non "spaced" form is doing a site search.

</comment><comment><USER4> The Spectrum's print edition is exceptional; That being said though, any moderate technologist can read the Spectrum. The Spectrum is not a collection of whitepapers, but a series of articles on broad topics and even investigative reporting that I wish were more mainstream (e.g. Dec. 2009 article on what its like to run an electrical generating station in Gaza). Pretty much any Wired reacher can handle it if they can stand not having a liquor ad on every other page.

</comment><comment><USER5> Actually, arXiv.org beats out IEEE, only proving what us scientists knew all along :)

[http://www.google.com/search?q=site%3Aarxiv.org&tbs=rl%3...](http://www.google.com/search?q=site%3Aarxiv.org&tbs=rl%3A1)

<comment><USER6> Apparently, the semantic web is serious business!

[http://www.google.com/search?q=site:www.w3.org/RDF/FAQ&h...](http://www.google.com/search?q=site:www.w3.org/RDF/FAQ&hl=en&num=10&lr=&ft=i&cr=&safe=images&tbs=rl:1)</comment></comment>


The best, and worst, of Demo Fall 2008 - <AUTHOR> http://www.infoworld.com/article/08/09/10/37NF-demo2008-best-worst_1.html

<comment><USER2> It is interesting to note that the majority of startups at DEMO are hardware companies while most at TechCrunch50 are software companies.

<comment><USER3> Is that by design or just by random chance?

<comment><USER2> Perhaps it is because it is more likely for a hardware company to be able to afford the $18500 fee for DEMO, while software companies are generally poorer and might chose to go the cheaper TC50 route.</comment></comment></comment>


Impressive backyard engineering on an obscure YouTube channel - <AUTHOR> https://www.thedrive.com/news/34554/some-of-the-most-impressive-backyard-engineering-weve-seen-goes-down-on-this-obscure-youtube-channel <comment><USER2> Quite like this boatbuilder in RI building small boats completely from milling the tree to finished product.

[https://www.youtube.com/watch?v=C22Crc7XHoI&list=PLzlN3A2DLg...](https://www.youtube.com/watch?v=C22Crc7XHoI&list=PLzlN3A2DLgNwE2RCpQ9vKCmeOwvKCRRjF)

<comment><USER3> Louis Sauzedde isn't exactly an amateur, but his videos are wonderful. Folks should also check out Acorn to Arabella, actual amateurs, or Tally Ho. A couple of other fascinating wooden boat building projects.

<comment><USER4> All of the Tally Ho project videos are great, but folks interested in "backyard engineering" might enjoy this one about getting live oak from sawyer Steve Cross in Georgia who built his giant saw out of several forklifts and assorted other machines.

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

<comment><USER3> One of my favorites. That man is a national treasure.

</comment></comment></comment></comment><comment><USER5> People talk about the old internet and how it used to be full of people sharing their interests and obsessions. I would argue that content on Youtube is intersecting the Geocities end of that period. Every oddball thing you could look up in 2000 is happening right now in someone's backyard on Youtube. Also ten times as many worthless spam videos, but this also correlates with the Geocities period. I don't like Youtube for a lot of reasons, but I love how it's illustrating that the nostalgic internet wasn't so much a contextual or cultural thing, it was more about the result of easy access to DIY publishing and the means to discover the results.

<comment><USER6> An apt comparison. I'm also worried of what will be of this immense amount of content when YT will go the way of the dodo.

</comment></comment><comment><USER7> Computerphile [https://www.youtube.com/channel/UC9-y-6csu5WGm29I7JiwpnA](https://www.youtube.com/channel/UC9-y-6csu5WGm29I7JiwpnA)

GOTO [https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA](https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA)

How To Make Everything [https://www.youtube.com/channel/UCfIqCzQJXvYj9ssCoHq327g](https://www.youtube.com/channel/UCfIqCzQJXvYj9ssCoHq327g)

Mind Your Decisions [https://www.youtube.com/channel/UCHnj59g7jezwTy5GeL8EA_g](https://www.youtube.com/channel/UCHnj59g7jezwTy5GeL8EA_g)

In One Lesson [https://www.youtube.com/channel/UC6eaVn7349LRh5yzpXjeu8A](https://www.youtube.com/channel/UC6eaVn7349LRh5yzpXjeu8A)

The Engineering Mindset [https://www.youtube.com/channel/UCk0fGHsCEzGig- rSzkfCjMw](https://www.youtube.com/channel/UCk0fGHsCEzGig-rSzkfCjMw)

<comment><USER8> That "How To Make Everything" site is pretty funny, esp. is $3500 salad. It reminds me of the book, "The $64 Tomato". About a guy that spends tons of money to grow a tomato and that's what the final cost turns out to be.

Here: [https://www.npr.org/templates/story/story.php?storyId=536076...](https://www.npr.org/templates/story/story.php?storyId=5360768)

<comment><USER9> I'm not sure what the author of the $64 tomato intented to convey... he spent $16k out of the gate on a new hobby, then calculated that his tomatoes cost $64 each.

Wanna know how much my tomatoes cost in my first garden?

1 food-grade plastic bucket, with holes drilled in the bottom: $5 ($60 or so if you include the drill and drill bit. I already owned a drill. I could have used a screwdriver and a hammer, or a nail and a rock, but whatever)

1 gallon of soil ($10 if you count the entire bag. I used the rest for other things, but we'll count the entire bag here)

Chicken wire to protect it ($30 if you count the entire roll. I used a few feet. I used the rest in other places.)

Some bamboo to use as a trellis (I don't remember. $5? $3? Lets say $5)

soo... $110, including a drill and a bunch of extras.

I'm on my third year with this setup. First year, I got about 20 tomatoes? Next year, none (whoops. It happens). This year, looking like I'll get another 20.

20/110=$5 each 40/110=$2.75 each

but, that's just one plant. I have three, so, it's really closer to 60+0(I goofed last year)+60 120/110=$1. Hey, we're cheaper than the store here, and it'll be better next year. If we leave out the drill and only calculate the costs per plant, and include the rest of the garden, I came out ahead in the first year.

Just... don't buy friggin cedar posts, wraught iron gates, spend $8k on design (!?! what're you doing ?!?!)... and your garden will make more sense than this guy's Instagram-worthy waste of money.

<comment><USER8> Good for you! You win the tomato grower prize!

The story is about an obsession that is also a backstory for a larger narrative about consumerism. If that doesn't interest you, fine, just admit it. You clearly didn't read the book, so why bother commenting how good you are at growing tomatos?

And, lol, this book took place two decades before Instagram but it was largely anticipating it, but you didn't read the book so the irony is lost.

<comment><USER9> take a drink man, relax.

It makes more sense when you say there's a backstory about consumerism in there.

Because saying "Hey, we have $64 tomatoes," on a blog entry that doesn't mention the rest of the book's focus on consumerism, with the scant details on the blog, comes off as "don't bother gardening, it costs a lot more than the store."

And no, I haven't read the book, but now that I know what it's about, it doesn't seem necessary. People buying unnecessary stuff to look good led to an unnecessarily expensive outcome.

</comment></comment></comment></comment></comment><comment><USER10> You'll love this one, Allen Millyard uses a hand hacksaw & his BBQ to make a Kawasaki Super Six and a Viper powered motorcycle. [https://www.youtube.com/user/millyardviper](https://www.youtube.com/user/millyardviper)

<comment><USER11> I've been watching his videos as well. I was surprised by the lack of equipment he has to build what he does. It shows just what you can do yourself at home if you have the skill.

Extremely interesting, channel.

</comment></comment><comment><USER12> Tech Ingredients is another channel on YouTube that constantly blows my mind. The explanations are well paced, thorough, and incredibly well done. The experiments are impressive, and the team (family) is obviously smart and quite disciplined.

[https://www.youtube.com/user/TechIngredients](https://www.youtube.com/user/TechIngredients)

<comment><USER13> Applied Science is also ridiculous. He's made so many things from scratch that require reading patents and endless experiments, e.g. photochromic glass, LCD screens, an EDM drill, chocolate holograms, air bearings, etc.

<comment><USER14> Applied Science and Tech Ingredients are both in a league of their own when it comes to at home engineering. Really inspirational and humbling guys.

</comment></comment></comment><comment><USER15> I'll have to rate Project Binky: Fitting the running gear from a Celica GT4 into an Austin Mini as one of the most epic youtube series ever. They're definitely quality over quantity as it's a side endeavor from their main business. 32 videos in seven years.

[https://www.youtube.com/playlist?list=PLGSOZAHg1yQHU1tc_3Y5M...](https://www.youtube.com/playlist?list=PLGSOZAHg1yQHU1tc_3Y5MTQg1qjtxA_nq)

</comment><comment><USER11> Surprised not seen Colinfurze mentioned. 10 million subscribers, was a plumber, no official engineering experience. If you look through the history of the channel you can see how his skills/builds have evolved over the years. [https://www.youtube.com/user/colinfurze](https://www.youtube.com/user/colinfurze)

</comment><comment><USER16> TL;DR here is just the channel: [https://www.youtube.com/channel/UCaCd1zq5Z3FmKdbxLDME7tg](https://www.youtube.com/channel/UCaCd1zq5Z3FmKdbxLDME7tg)

<comment><USER17> Thanks, here is another such channel Mr.Teslonian - [https://www.youtube.com/user/MrTeslonian](https://www.youtube.com/user/MrTeslonian).

The common theme behind these good maker videos seems to be -

•Low quality camera (at least not Hollywood grade RED cameras), but I do wish they shoot in 1080p60.

•Shot by themselves/Tripod.

•Not edited extensively.

•No Intro/Outro.

•Often not monetised (Although I wish they get monetary benefits for their effort), so videos are short as there's no pressure to artificially inflate content over 10 mins for Ads.

In summary, it's like they are struck with YouTube of 2005.

Mr.Teslonian experimented with several mask designs, he made one with coffee filter[1] and I was able to reproduce the same with qualitative filter[2].

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

[2][https://abishekmuthian.com/diy-qualitative-filter-face- mask/](https://abishekmuthian.com/diy-qualitative-filter-face-mask/)

<comment><USER18> I've had comments about my channel similar to those. "Stuck in Youtube 2005". I've also been told my site has a web 1.0 feel too it. I take it as a compliment.

I don't really call myself a "maker" but more of a serial tinkerer, but I'm more worried about content than quality.

If you got the gist of what I'm doing, and I didn't have to spend hours editing it, then it's good enough. I still use Windows Movie Maker! And yes I am familiar with Davinci Resolve, but I don't care to use it unless I have to for some reason. Most of my stuff is filmed with my tablet on a tripod in 720p/30fps because it's what I have. I don't have the money to spend on gopros. I'm in it for building/fixing/hacking stuff, not for being Youtube famous.

<comment><USER17> Sounds good. I hope I needn't clarify myself for telling 'YouTube of 2005' as a compliment.

I've had YouTube channels in the past with few thousand subscribers, but now I've recently resigned myself into making non edited videos on my personal channel. My aim is to just have a stable camera setup & good quality audio for the sake of the audience.

I think the difference we're talking about here is 'Making videos for ourselves, others like us vs making video purely for scaling up the audience'. IMO, former can help in retaining our sanity, but latter can make us rich at the same time constantly looking for acknowledgement from others.

</comment></comment></comment></comment><comment><USER19> His neighbors must love him for all these peaceful and quiet days/weekends.

<comment><USER20> Probably depends on the neighbors. If I was his neighbor I'd ask if I could come over and watch.

</comment></comment><comment><USER21> Is there any good channels that are about building log houses from start to finish?

<comment><USER22> This guy is doing that: [https://m.youtube.com/user/nikrijavec](https://m.youtube.com/user/nikrijavec)

I've only watched the two hour compilation of the first year, but I think he has a lot more videos that are probably more in depth.

<comment><USER23> I've watched every one of his videos ... at least out of the corner of my eye. The length of these videos and the small amount of talking makes them somehow relaxing.

</comment></comment></comment><comment><USER24> Highly addictive: [https://www.youtube.com/user/engineerguyvideo](https://www.youtube.com/user/engineerguyvideo)

</comment><comment><USER25> Are there similar channels for software engineering? I'm aware of Engineering Man, other than that?

<comment><USER26> "javidx9" is probably exactly what you're looking for. His "Forbidden C++" is a pretty good video. A vague awhile ago he had a pretty cool video explaining how you optimize Mandelbrot rendering that was the most succinct example I've ever seen of optimization.

"moshix" is more of a mainframe sysprog but maybe 20% of the content is 60s era COBOL and similar. A dirty secret of worship of the young in software development is every big problem is an old problem, and there's lots to learn from the ancients and how they handled the EXACT same problems in a slightly different format.

"code maven" not entirely sure this meets the critera, not sure that it doesn't. "skeleton go program" sure, "how to use linkedin to find a job" I donno if that counts?

"Ralph S Bacon" is a bit more embedded/Arduino, but if you like C development and blinking LEDs and what I'm told is british humour...

"Ben Eater" is like Ralphie but more retro (you'll see more 6502 assembly on Ben's channel and more arduino on Ralphies channel)

"The 8-Bit Guy" is like Ben Eater but more systems oriented than writing assembly. The way he hints at stuff I bet he's memorized the 6502 instruction set like anyone else, he just focuses hard on higher level systems issues.

"The Signal Path" is a bit more programming with solder aka analog electronics but he does bravely delve into the digital world on occasion.

Naomi Wu's channel, well, maybe she writes code 5% of the time ... but the IDE cursor is up here guys. I'm not saying it doesn't qualify or that it does qualify. Its, um, unique, that's for sure. Borderline NSFW, depending where you work...

Just because software is eating the world, some cool stuff is tangential but not focused on SE.

"Huygens Optics" is primarily about photons but as software eats the world his CNC controlled lens grinders and python scripts to simulate optical systems becomes tangentially SE.

"Applied Science" is like Huygens-bro where its not officially software development but with software eating the world I get the feeling that dude is pretty handy with an IDE although he doesn't brag about it.

"Sam Zeloof" is the same deal as above, people trying to make home semiconductors spend most of their time on the tools rather than actually making chips, and as above software eats the world so everything seems to revolve around writing a Python script to automate your heterodyne interfereometer and similar challenges.

<comment><USER27> "The Cherno" is a game developer (used to work at EA) who builds a game engine and vlogs about it, with the source on github. He also has videos on C++ and other subjects (recently a reaction on the PS5 and on the UE5 demo; Youtube recommended it to me for that)

</comment></comment></comment><comment><USER8> That is some crazy stuff. I always wonder what's hiding out there in the unseen corners of (SFL!) YouTube.

I would really like to experiment with engines like this, but decades of experience indicates I am prone to self-injury, and I don't think there would be any "small" injuries with propane jet engines.</comment>


Show HN: A Rails webapp that stores health data and auto-fills medical forms - health-techie http://www.happyhealth.me

<comment><AUTHOR> Some quick feedback after trying the demo:

1\. Your www.happyhealth.me worked, but leaving off the www (happyhealth.me) didn't. Need to add a DNS record so both work. (be sure to redirect users to one or the other so your analytics are consistant.)

2\. When I'm viewing my profile on a different tab (for example, Medical), then I press the edit button, I'm shown the Personal tab rather than the Medical tab. To fix this, you could store the current tab in the session and pop them over to that tab when they click the edit button.

3\. Looks like I'm only able to add three allergies and three medications to my profile. Might want to make a little 'add more' button to those, or just always show an extra empty field(s) when editing these.

4\. On a similar note, it was unclear how to remove a medication from the profile.

5\. When viewing the Midwest Health Center form, the race / ethnicity was left blank even though I added that information to the test profile. Same for a test middle initial on another test form. (I realize this is a test profile and may not yet be complete)

6\. Just a suggestion, but I'd leave off the signed date incase the person is printing the forms a day or two early.

7\. I'd also suggest that you do not ask for / keep the social security numbers for anyone. Other information like address, phone numbers, etc. are (to me) o.k. to submit to the form, but the social security number is something I'd not be comfortable sharing with a convenience application like this. Might be better if you instead flagged areas on the various forms where this sensitive information should be hand-entered, where you needed to sign, etc. I also realize that once printed out, or handed to an office staff, this sensitive information is no longer secure, not keeping this info in your application would reduce your liability / worry about stuff like that.

8\. Another quick suggestion is to add a place to store your preferred pharmacy.

Looks like a lot of work went into this so far. Like I commented earlier, a service like this would be a big time saver for people.

</comment><comment> health-techie It's a simple personal health record (PHR) that securely stores health information like demographics, insurance, meds/allergies, etc, and uses that info to auto-fill those annoying doctor's office forms.

It's a simple version of ZocDoc's "Check-in" service, but we want it to be a free tool for use at any doctor's office; just request an office, and we'll upload the forms and make them available.

We're in private beta and would love the feedback on the demo. Sign-in with 'health100'.

<comment><AUTHOR> Pretty neat. I can see this being a huge time-saver. Whenever I have to fill out these kinds of forms, I always wish there were a central API that doctors / dentists / etc. could pull my information from. I also think that it's silly to write it on a piece of paper that someone else, then, has to enter into their database.

May I ask what you are using to generate the PDFs? I am working on a project to help science fair students fill out their ISEF paperwork and am using the pdfkit gem which seems to work pretty well. Looks like you might be doing something similar—especially when you're placing fields on an image background (fax).

<comment> health-techie "... I always wish there were a central API that doctors / dentists / etc. could pull my information from."

Took the words right out of my mouth. The long-term goal would for this to become the definitive single sign-on solution for any medical registration scenario.

As for PDF generation, happyhealth does use pdfkit.

</comment></comment></comment><comment><USER2> Is this actually HIPAA compliant? Assuming the information falls under HIPAA, is this group actually saving it on a certified HIPAA compliant server?

<comment> health-techie We are definitely using HIPAA-compliant methods of data encryption for transmission and storage within the cloud.</comment></comment>


The correlation between IQ and income - <AUTHOR> https://pumpkinperson.com/2016/02/11/the-incredible-correlation-between-iq-income/ <comment><USER2> This article is built around an error in statistical inference. The author uses aggregate data to fit a linear model, then erroneously supposes the slope can be applied to data at the individual level.

It can't.

For example, there are very few megarich people, but the aggregate model gives them 1 (of the 7) data points. That's a lot of weight for a very small group.

</comment><comment><USER3> From the article:

"It's common knowledge in psychometric circles that reading comprehension tests are statistically equivalent to IQ tests"

I'm not sure why the author throws this out there, then ignores it. English proficiency is tightly correlated with SES in the US, and one of the historical criticisms of IQ testing is that it mostly tests your ability to understand the questions on the test rather than underlying cognitive capability.

As a result, any conclusions about an IQ gap may be attributable to an education gap, which I doubt very many people would deny exists.

</comment><comment><USER4> So, low IQ people earn less money because they have lower IQ or they have lower IQ because they earn less money? Higher income implies better lifestyle.

Sorry for bad english.

</comment><comment><USER5> Has the author ever visited LA? I'm surrounded by rich idiots here.

</comment><comment><USER6> Ther interwebz says I score 127. Where's my McMansion?

</comment><comment><USER7> > One problem with this study is that 81% of the sample was black (much higher > than the 45% among homeless Americans in general) and these tend to score > lower on IQ tests, at least in the general population, however a UK sample > of homeless obtained virtually identical scores on the WASI, despite being > 96% white.

Uhhh....REALLY not sure what to make of this paragraph. If I'm not missing something, seems to be implying that there's a correlation between race and IQ. This is on HN?

<comment><USER8> This is not a controversial opinion. It is a statistical fact of psychometrics.

<comment><USER7> I would be interested to see the results for a comparison of black and white individuals _with comparable upbringings._

I have a very, _very_ hard time believing this.

Yes, if you compare the cognitive ability of someone in a 3rd world country to that of someone in a first world country, or someone who grew up in poverty to someone who grew up comfortably, I would be unsurprised to see a difference.

I would be intrigued to be linked to any peer-reviewed study that is not colored by those factors.

<comment><USER8> Here is a good start

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

<comment><USER7> Did you read your own source?

> Currently, there is no non-circumstantial evidence that these differences in > test scores have a genetic component,

\---

> Soon, other studies appeared, contesting these conclusions and arguing > instead that the Army tests had not adequately controlled for the > environmental factors such as socio-economic and educational inequality > between African-Americans and Whites.

\----

> The majority of anthropologists today consider race to be a sociopolitical > phenomenon rather than a biological one,[34] a view supported by > considerable genetics research.

<comment><USER8> I didn't mean to imply that I knew the answer to your question. I meant that the IQ disparity is a statistical fact, but the cause is a hotly debated area of research without clear answers, and the Wikipedia page is a good primer on the various sides of the debate. The point is that in a study like this you may have to adjust for oversampling by race.</comment></comment></comment></comment></comment></comment>


Hyperleveldb - <AUTHOR> http://hackingdistributed.com/2013/06/17/hyperleveldb/ <comment><USER2> It's interesting that one of the most popular uses of LevelDB is in Bitcoin (and its forks) and it isn't mentioned in this article. Especially since there are so many other bitcoin articles on this site.</comment>


Pinspire.com - <AUTHOR> http://www.pinspire.com/hot <comment><USER2> I know imitation is supposed to be the sincerest form of flattery™ but this is ridiculous. This is just a direct copy of Pinterest. I really hope this is a joke or someone's development practice.

</comment><comment><USER3> I'm not one to rain on anyone's parade, and great artists steal, etc etc, but isn't this a complete ripoff of Pinterest?

<comment><USER4> Yea I have to second you on that as I was completely fooled for a second...how is this different from Pinterest?

<comment><USER5> It's European ;-)

But no. As far as I can tell it's Pinterest. Maybe they're hoping to get acquired?

<comment><USER2> acquired... or sued?

</comment></comment></comment></comment><comment><USER6> That's nuts, I can't believe they even copied the name.</comment>


Facebook Launches Standalone Groups App - <AUTHOR> http://techcrunch.com/2014/11/18/facebook-launches-standalone-groups-app/

<comment><USER2> Called it! Check out my blog post from 2 days ago: [https://news.ycombinator.com/item?id=8613878](https://news.ycombinator.com/item?id=8613878)

</comment><comment><USER3> I might try this app out. I recently turned my Facebook off due to privacy concerns. However I found I was missing out on really important stuff like family reunions, engagements, new baby pictures.

I currently browse facebook only in a private tab, mostly as a response to frictionless sharing.

If I could only consume the part of facebook that I need to stay in touch with family that would be great.

<comment><USER4> Hm what's wrong with making phone calls, writing emails / letter to do that? Send them baby pictures by post for christmas or something.

<comment><USER5> Extra clicks and time needed to do it comes into consideration.

Usually about now is when someone claims, "If they were your _real_ friend they would put forth the effort.", but by that logic, if you were their _real_ friend you would put in the effort in to make yourself easier to share with.

</comment></comment></comment><comment><USER6> Always thought facebook can challenge meetup.com, will wait to see if like minded groups will use this with referal only entry

</comment><comment><USER7> I find Facebook lists to be a lot more convenient for "micro-sharing". The lists are completely on your end, and none of your friends know what list they are on. It just makes it so that everything from you is targeted to them .

</comment><comment><USER8> Given the amount of vitriol surrounding Facebook messenger as a separate app, I'll be interested to see how users respond to this new head that has spawned on the Facebook app hydra. Looks like a direct competitor to Groupme and Whatsapp groups, and one that could've (should've?) been implemented within the messenger app rather than building out a completely separate application for chats that probably already live inside messenger.

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

</comment><comment><USER10> I really appreciate FB splitting off their features into products. I use the Chat app a lot more than I was expecting. I seldom view the "news feed" which is mostly garbage for me. I look forward to an "Event planning" and calendar integration...

</comment><comment><USER11> Why can't they just make all the same features that are on the main web site available in the main app? I use groups a whole lot but I see no need for a separate app... that just means more context switching and will most likely lead to app jumping like main vs messenger does now :/

<comment><USER12> For one not-minor advantage, you get context to badging and push notifications. I have the notifications from the Facebook app itself completely disabled because it's a flood of non-urgent interrupts—but I rely on notifications on the Facebook Messenger app, and would probably leave notifications enabled on Facebook Groups if I had a group I participated heavily in. It'd be sort of like Pair, or Slack (but for non-company groups), both of which are disruptive sub-markets that are eating Facebook's lunch.

</comment></comment><comment><USER13> edited: Sorry I confused Groups and Rooms! ignore this.

\</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>

A couple of UX decisions in the Rooms app are interesting.

It uses QR Codes to provide access to a Room. You take a screenshot of the QR code, the Rooms app scans your camera roll to find new rooms to give you access to.

The typical account creation process is side-stepped. You create an account after you use the app. The account is initially based on your device, so it's only needed if you switch devices or use multiple devices.

<comment><USER5> That's rooms, not groups.

It makes it difficult to get more users into a room, and [seems to] pander for mobile interaction.

</comment></comment><comment><USER14> What do you think your biggest use cases will be for the new Facebook Groups app?

I'm curious, because in the past, Facebook Groups seemed to be forums basically.

<comment><USER15> I have groups for:

-My football tipping group

-My D&D group

-My board games group

-A group of my closeish (25 members) friends used to organise events and general chit chat which we aren't necessarily comfortable sharing with all of Facebook.

For me, the valuable features of Facebook are now groups and events, everything else is just junk.

<comment><USER14> I wonder what you'd think of an app dedicated solely to real-life groups and events:

[http://qbixstaging.com/Groups](http://qbixstaging.com/Groups)

Try it out and let me know your feedback. Planning to release it soon.

</comment></comment></comment><comment><USER16> Is the app in the iTunes store yet?

<comment><USER17> Try this link: [https://itunes.apple.com/app/id931735837](https://itunes.apple.com/app/id931735837)</comment></comment>


Being a CTO at a small digital agency - <AUTHOR> https://www.linkedin.com/pulse/being-cto-small-digital-agency-vadim-kravcenko/ <comment><AUTHOR> Hey everyone, I thought maybe it can be interesting for some oof you, I know there are a lot of aspiring developers here who want to know what's it like being a CTO.</comment>