How can I write an interface like Gmail? - <AUTHOR>

I am a python hacker.  I want to give a gmail-like interface to my web app.  What tools are the best to consider?? <comment><USER2> Imo, the most important technique (besides standard ajax with js lib of choice) is making use of hashchange and organizing your behavior into 'routes' based on the hash. You'll notice that Gmail does this -- it has URIs ending with #inbox, #label/action, etc.

Using hash routes allows you to keep track of state and decouple event handlers that set state from code that updates the page. Plus you get back button functionality and bookmark support.

Some background info on hashchange: <http://blog.whatwg.org/this-week-in- html-5-episode-3>

jquery library for dealing directly with hashchange: <http://benalman.com/projects/jquery-bbq-plugin/>

Higher-level jquery library for handling hashchange: <http://code.quirkey.com/sammy/> . It has more assumptions and imposes more constraints on the structure of your code. But in return you get route parsing and a DSL.

If you go through the examples/tutorials in those two libraries you should gain enough knowledge to get started.

<comment><USER3> if you can map these hashes to actual URLs, you can get rid of hashes entirely by using HTML5's history methods. see: [https://developer.mozilla.org/en/DOM/Manipulating_the_browse...](https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history) you can fall back on hashes for browsers without support.

the first implementation i've seen of this is in Flickr. i was amazed when i ran into it yesterday. you have to be signed in to preview the new photo pages, but the zoomed/lightboxed photo pages use HTML5 history in compatible browsers and fall back when they can't. their JS is viewable at: <http://l.yimg.com/g/combo.gne?j/history-manager.js.v90829.14>

</comment></comment><comment><USER4> I'm not sure if you asking exactly this, but here's what I'll tell you. We're building a frontend interface for our webapp now (almost finished) and I have to say it's a difficult design task, in terms of code, of course. The truth is that libraries like jQuery have really nothing to do with building interfaces. They have a couple of effects, a couple of useful shortcuts (like selecting dom elements easily), a couple of solved issues (like browser compatibility), but if you're going to write an interface - be ready to give a good thought about how to arrange the code, so that it would not look ugly.

Especially because we're talking js now, I think it's a hell of a task, as I have this impression the language was designed to duplicate as much code as you possibly can. It's not Python or Ruby and you have to understand it inside out to make it right. In Ruby, for example, it's easy to write nice looking code even if you're a beginner. I haven't tried ExtJS or some other frameworks, maybe they provide some necessary background that helps you organize things better. But jQuery and Prototype definitely don't do that. Then there's the question of testing, which is a pain in the ass in javascript, even though we have nice tools like jspec.

So I'd be really careful. Chances are you'll end up with lots of crappy code in js that would be hard to maintain, especially if your frontend is big and you don't have experience in creating interface frameworks.

<comment><USER5> > I have this impression the language was designed to duplicate as much code > as you possibly can

You're right about the limits of jquery, but JavaScript is not like Java inasmuch as repetitious JavaScript is a near-sure sign that you're doing it wrong. I'm working on a larger script too these days, and code organization is a problem for me, too, but repetition isn't really.

<comment><USER4> unDRY code is a problem for me in JavaScript probably because I don't have too much experience. The point is: you can write DRY code in js, it's just not as easy as in Ruby. Also, here's an example: [http://stackoverflow.com/questions/3077335/how-do-i- implemen...](http://stackoverflow.com/questions/3077335/how-do-i-implement-a- before-filter-callback-in-javascript)

I managed to find a better answer than it is suggested there, though.

</comment></comment></comment><comment><USER6> Well you definitely need something to handle AJAX. I pick between Prototype and jQuery, depending on the project. Sometimes I mix and match with both, since jQuery can coexist.

Next, you need to decide whether you will transport XML/JSON and have client- side code stick in in the DOM, or eval the AJAX response. In the latter case, you need to be generating JavaScript on the server-side. I know the Ruby on Rails RJS piece of the stack can be extracted from Rails 3, but I'm unsure about Python, so you might be better off taking the former approach.

There's a lot you can do with regards to animation in Prototype/jQuery alone, but I like Scriptaculous, and I've heard good things about MooTools.

Making a GMail-like interface isn't all about XML-HTTP-Requests though. There's a lot of value in nailing the usability, the basic concept. Then there's maintaining the history, undoable actions, HTML fallback and such.

My best advice is to start building a decent static interface from the ground up, and when you have it nailed, just augment all the minor GET actions with AJAX first (like going back to the index after reading an email). Then enhance primary POST and UPDATE actions (replying, marking with a star, moving to archive).

Half way through, you'll probably notice most of the page reloads that remain are acceptable. At that point, focus on refining the original concept with new methodologies you picked up along the way.

It's just the way I do it though, make sure you investigate other suggestions to find a perfect fit (by the looks of it, GWT is quite a paradigm-shift).

</comment><comment><USER7> Gmail's interface is unique in that the rendering is being done by a Javascript Controller in a hidden iframe. Gmail itself only requests raw data over the wire.

If you just want the look and feel of Gmail, there are plenty of frameworks referenced in the comments (Cappucinno, YUI2, Sencha, etc) that can give you the basic layout. But if you want the mimic the speed/functionality, it'll require getting dirty with Javascript controller design in the browser.

<comment><USER8> Can you elaborate on this? So it isn't being done by just modifying the DOM with Javascript? Why the hidden iframe?

<comment><USER7> Sure. The hidden iframe allows you to do 3 things: 1) preserve state across view changes (mail vs. preferences, etc) 2) isolate code 3) reduce over-the- wire data size because all the rendering/UI generation is happening in- browser.

If you take a look at gmail in a debugger you'll see there are 4 iframes. The controller is the 'js_frame', the 'canvas' contains the graphic UI elements.

Leaving the canvas in its own iframe allows it to be reloaded separately without affecting application state.

Javascript still modifies the canvas iframe DOM. But that modification is cross-frame from the controller iframe.

I used a similar frame-based technique back in '97 when our enterprise startup needed a snappy native-looking zero-deploy UI.

</comment></comment></comment><comment><USER9> Not Python, but there are a few Rich Internet Application (RIA) frameworks you should look at if you don't want to do low-level HTML/CSS/JS work (still the most common approach, mind you). GWT is the most popular, but probably only worth using if you're Java-fluent. Here are a couple of others:

Caoouccino/Objective-J, from the YC-funded 180north guys. It's an Onjective-C like language that compiles to web apps (and now Mac apps, too). It was used recently to create a Github issue tracker app, which looks pretty sweet.

<http://cappucinno.org>

No one seems to have mentioned SproutCore, which had a lot of buzz for a while since Apple was using it to develop their own webapps. It had a 1.0 release just a few months ago, but the buzz seems to have died down and I haven't seen any new projects using it. Apple is using something else now. Still, it's one option to check out:

<http://sproutcore.com>

Finally, if you do wind up working at the JavaScript level, I strongly recommend that you try CoffeeScript, which has a very Python-like syntax yet compiles directly to JavaScript. I've used it with jQuery for some pretty complex apps, and it's definitely made me a lot more productive:

<http://coffeescript.org>

<comment><USER10> fixin some typos <http://cappuccino.org/> 280north Objective-C

<comment><USER9> Thanks. That's what I get for posting to HN via iPad...

</comment></comment></comment><comment><USER11> Not to quaffle, but please do add 'Ask HN' the next time you post a question.

<comment><USER12> If it's a "self" post (has no domain name after the link indicating an external link) and it's a question, who else would he be asking?

<comment><USER13> Not that I have a dog in this race, but sometimes seemingly arbitrary convention can be exploited. For instance, some pioneering lad[y] might be compiling a collection of Ask-HN-questions. It's easy to see why it would be nice to have "Ask HN" in the title. Convention implies "easier to parse", and that makes programmers happy.

</comment></comment></comment><comment><USER14> <http://cappuccino.org/> and some python on the backend for REST interaction.

Or GWT, just like GMail.

<comment><USER15> Not to be snarky but, GMail isn't written in GWT.

GWT though would be a step towards the OP's solution.

<comment><USER16> How sure are you in your claim? Any proof that GMail is not written in GWT?

<comment><AUTHOR> Gmail was written using Closure library built by google itself. Google release it for open source community now.

<comment><USER16> That is not proof, just another statement that means nothing without supporting data.

Also, if GMail is such a successful use case for Closure library, one could wonder why did they build Google Wave client with GWT?

</comment></comment></comment></comment></comment><comment><USER17> I'm currently evaluating WT (www.Webtoolkit.eu) which is the C++ equivalent of GWT. I noticed that WT examples were much faster than GWT's examples on my iPad. For python, I think Django should be the way to go.

<comment><USER18> Dude, i am impressed.WT really rock!.Just one problem how do Python programmer learn C++ fast?

</comment></comment><comment><USER19> Although you're a Python hacker, you may want to save yourself some time and use NOLOH (<http://www.noloh.com>). It handles most of the aspects of development that usually distract you and let you focus on your core application. It features a lightweight and on-demand core that offers cross- browser compatibility, automatic AJAX, search-engine-friendly, numerous syntactic features to make developing in it a joy, and much much more.

You can read more about it the website, user blogs, or in this month's php|architect magazine cover story <http://www.phparch.com/magazine/2010/may/>.

Note that if you're really interested you can join us in our #noloh IRC room and someone can help you put together a prototype in relative short order.

Disclaimer: I'm a co-founder of NOLOH.

</comment><comment><USER20> I'm a Mootools fan myself. I use it over the seemingly more popular libs like jquery because very little of my JS code is actually touching DOM. I usually start my projects by creating all my "classes" (actually prototypes, etc, but classes make sense to most OO people).

I primarily code in Py, but I do really want to sit down with GWT some day, it looks badass.

In a lot of my projects I just use raw JS. Big libraries scare me sometimes and honestly, JS isn't that hard if you know what you're doing and know how to code around the main browser issues. I like some of the functional paradigms from mootools though (well any other lib for that matter), and the XHR handling.

(sorry I didn't really answer your question -- just rambled a bit before I go to sleep)

</comment><comment><USER21> Visually, perhaps you can take something from this example which mimics Google wave layout using the ukijs javascript framework.

<http://ukijs.org/examples/core-examples/wave/>

</comment><comment><USER22> I'm working on a neat project to integrate pylons with pyjamas for this very task.

Pyjamas is an RIA framework that started as a port of GWT to Python. Development has recently sparked up and they now offer new features beyond what GWT can offer.

In order to integrate pylons with pyjamas, I've started work on a JSONRPCController base class that I hope will eventually be included in pylons. Eventually I'd like to add other things like a project template and setuptools commands for compiling and deploying a pylons+pyjamas app.

You can get a peek at what I've started on my blog: <http://agentultra.com>

<comment><AUTHOR> I am playing with pyjamas currently. It is not working properly with chrome. I am trying to resolve that issue now.

</comment></comment><comment><USER23> I think you could limit python for server tasks(data read/write, security and authentication). We use Erlang for that.

Then choose in which language the server talks to the world(browsers, mobile apps, native apps, flash,...) usually through json or xml services, REST or not. You are building your API at the same time.

For each platform you can choose different techniques depending on your skills and needs. I'm not a fan of auto-pilot frameworks. I always felt they force me to think their way to build my thoughts(a personal limitation probably).

When we faced this decision to build our app, we took HTML5. We know it well and it works on all platforms. Native apps are cool, but we can't afford them as a startup.

Then on the browser, when you get the data you have to represent them. I was a fan of XML+XSLT and used to templating logic on the browser. We use JSON now, and have built a template engine(PURE) for a similar approach and get a fast HTML rendering of JSON data.

And we took jquery to cope with the DOM and browser differences.

The server streams only data, the network likes it. The browser render all this very fast. And this makes a very responsive app.

</comment><comment><USER24> here's how <http://code.google.com/closure/> by google themselfs

</comment><comment><USER25> Why is everyone a hacker these days?

BTW, GWT is one option. Some JS libraries such as JQuery is another.

<comment><USER26> don't we take pride in calling ourselves hackers? Why on earth otherwise are we on HN? :P

<comment><USER27> I don't remember where I read it, but you're only a _true_ hacker if some arbitrarily large enough community has bestowed that label upon you. As of today, hacker is almost synonymous with programmer, and people who can compile a C++ program sometimes think themselves as 'hackers'. It's kind of sad, but I don't really care. The media has long since killed the term for general usage.

<comment><USER28> We better start a Hacker Certification Program to make sure we can sort the true hackers from the fake ones.

Question 1: What is your hacker handle?

A1: Zero Cool, A2: Crash Override, A3: Acid Burn, A4: Cereal Killer (select one)

<comment><USER27> Heh, hell yeah.

Question 2: Which of these systems do you have control over? (Circle all that apply.)

A1: National Electric Grid A2: Local Electric Grid A3: Any Television Station A4: Any Cellphone Tower A5: Any Satellite A6: Your neighbor's wireless router

</comment></comment></comment></comment></comment><comment><USER29> I use a javascript MVC framework called Claypool for structuring my client- side code. It's really good! <http://docs.jquery.com/Plugins/Claypool>

</comment><comment><USER30> GWT is certainly a very useful tool for rich client web applications. If you are familiar with Java, it might be the quickest way to start building very complicated javascript based interfaces.

</comment><comment><USER31> You better ask: "How can WE write an interface like Gmail?"

</comment><comment><USER32> You need JavaScript, and though there are lots of libraries that make things simpler, you'll need a good understanding of JavaScript and preferably have a good understanding of the DOM as well.

Libraries will help you with the DOM, but not a ton. They won't help you with the js.

I suggest you start with a library, but make sure you understan what you're doing in terms of the DOM.

</comment><comment><USER33> ExtJS, now Sencha, is another option.

</comment><comment><USER34> There's also pyjs if you want to skip the writing of javascript and just write python. It works like gwt, but in python. <http://pyjs.org/>

</comment><comment><USER35> on top of things like using Ajax you might want to read up on RESTful web services for building services. Jquery and Jquery UI are great otherwise.</comment>


Maths Around the Clock (2018) - <AUTHOR> https://plus.maths.org/content/maths-around-clock <comment><USER2> This is a great link! If you enjoy weird clocks here's a vague clock I made: [https://oisinmoran.com/clock.html](https://oisinmoran.com/clock.html)

More closely related to this I also wanted to make one of these style of clocks from the article using just a single 4 along with the square root, factorial, and floor operations (from Knuth) although so far I haven't been able to get 9 or 12. I haven't worked on it in ages but you can play with the live calculations here, nicely typeset in KaTeX: [https://oisinmoran.com/projects/root_floor_fact_four.html](https://oisinmoran.com/projects/root_floor_fact_four.html)

</comment><comment><USER3> I've been to Chichen Itza and a few other Mayan sites but until I read this I didn't know of the Mayan numeral system.

Being base 20 it gets complicated for high numbers[1]

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

<comment><USER4> Broken link, I think you mean:

[https://en.wikipedia.org/wiki/Maya_numerals#Modified_vigesim...](https://en.wikipedia.org/wiki/Maya_numerals#Modified_vigesimal_system_in_the_Maya_calendar)

<comment><USER3> Yeah, I should have put a space between the link and "[1]"

EDIT: The "[1]" should have been at the start too!

</comment></comment></comment><comment><USER5> The Chinese Remainder Clock on Perucca's website is more interesting still:

[http://www.antonellaperucca.net/CRC.html](http://www.antonellaperucca.net/CRC.html)</comment>


The tech insiders who fear a smartphone dystopia - <AUTHOR> https://www.theguardian.com/technology/2017/oct/05/smartphone-addiction-silicon-valley-dystopia <comment><USER2> Social media and smart phone attention-grabbers are bad because they bring immediate rewards, but divert you from spending your time and energy on activities that are less immediately rewarding, but have far higher benefits in the long term.

The reason they work is our brains are designed for a foraging tribe existence in which the attention-grabbers a person would encounter generally elicited more functional behavior.

I don't think regulation can work here. It seems to me that the solution is some combination of people getting smarter and deciding to get off social media and turn off their smartphones, plus technology like steemit that avoid the economic model of advertising + selling personal data.</comment>


Parents Are Dumb and Kids Don't Know Anything About Computers Anymore - <AUTHOR> https://medium.com/@seibelj/parents-are-dumb-and-kids-don-t-know-anything-about-computers-anymore-b59e974d052c <comment><USER3> I think every generation has made the same claims about the dumbing down from the previous generation.

This piece paints the early 1990s as a golden era where you had to, and thus did, know about the computer at a low level. (And yes, I remember finding the DIP switches to change IRQ settings.)

But some of those of the previous generation would complain about how kids in the 1990s didn't know how to open up the box, and wire in new hardware, nor understand the circuit diagrams ... which no longer come with the computer.

Those of the first microcomputer generation, of the 1970s, would complain that those of the 1980s had no idea any more how to put things together themselves, like from an Altair kit, or go to Homebrew meetings and share schematics.

My uncle once drove me around in a Model A truck. The engine isn't sealed. The owner was expected to open it up an clean it every year. In earlier models, there was a door in the firewall to adjust the carburetor while driving. Obviously, we are now dumb, and know nothing about cars any more.

<comment><USER4> Your argument would make sense if computer knowledge had been replaced with something else of utility, in younger generations. What has it been replaced with?

<comment><USER3> Nearly all of that 'computer knowledge' I learned in the 1980s - DIP switches, IRQ lines, BIOS calls, how to undelete from a FAT16 directory, etc. - <USER2> transient knowledge that is about as useful now as learning to start a Model T by hand crank.

So here's a real example of utility. The son of a friend of mine, about 12 years old, uses his iPad to make stop motion animation. He once made a movie on the plane, and totally amazed a seatmate.

Could you or I have made such a thing in the 1980s? No. Well, not without a lot of expensive equipment.

Sure, there's no utility if you define "utility" as being able to understand hardware (or how to rebuild a Model T engine or a carburetor). But it's excellent utility for someone who wants to go into animation. He could be a co-founder of the next Aardman, for all we know.

The vast majority of kids with computers in the 1980s, btw, mostly used it to play games and do school reports.

Compare your experience to the R.E.S.I.S.T.O.R.S in the 1960s and 1970s, who started with their own vacuum tube computer, had a teletype to dial into a PDP-8 until DEC donated one to them, and more. Do you think the kids of 1990 really learned something of utility compared to that?

</comment></comment></comment><comment><USER5> When I was a kid we would spend days picking out the perfect site for a water mill. We'd toil getting a mill dam set up and some of the finest carpenters in town would build a great water wheel that would supply enough power to run the saws. Kids these days don't even know how to direct the flow of a stream and yet they are off creating a furniture with their table saws and electric compound miters. Their parents are dumb and the kids don't know anything about saws.</comment>


Microsoft Teams: Whiteboard - <AUTHOR> https://twitter.com/randychapman/status/1169884205141987332 <comment><USER2> Scrolling through the comments, I reached the impression that "content camera" was an established industry term I had never heard before. But, a quick search only finds relevant results in the context of this particular product/feature, and the second result is the documentation page for it:

[https://docs.microsoft.com/en-us/microsoftteams/room- systems...](https://docs.microsoft.com/en-us/microsoftteams/room- systems/content-camera)

"A content camera interacts with special image-processing software and a whiteboard to allow a presenter to draw on an analog whiteboard and share the content with remote participants."

</comment><comment><USER3> There's a really cool panorama camera called Panacast. It's meant for small to medium sized rooms. Does an excellent job of stitching the room together so you can see everyone in the room better.

They have their own whiteboard feature that the admin maps out in the software. Using their software and the camera, it can almost flawlessly recreate a whiteboard on the other side of the room as it's own input source without any noticeable curving in the image. It only works on Windows PCs. We use this in our Zoom Rooms and it's pretty neat. I believe it will work in other conferencing apps as well.

</comment><comment><USER4> I don't see myself using this, but its really cool. The whole "see through presenter" thing is awesome.

Somewhat unrelated, but it would be really cool to see that done using AR glasses.

<comment><USER5> > AR glasses

Why? If you're in the room you can see the whiteboard.

This is so people who aren't in the room can see it.

</comment></comment><comment><USER6> The deal breaker for me is Teams is unintuitive and has fewer integrations than Slack

</comment><comment><USER7> Just in time m. This is exactly what I need for a meeting in 2 days</comment>


Scandalous Weird Old Things About The C Preprocessor (2015) - <AUTHOR> http://blog.robertelder.org/7-weird-old-things-about-the-c-preprocessor/ <comment><USER2> A nit: the comment about how the C preprocessor can't be described by a context-free grammar is followed by a comment about how # directives are sensitive to where they are in the line. That's actually a non-sequitur! It's totally possible for context-free grammars to be line-oriented, the "context" in this sense has a very technical meaning--it means that the left side of a production rule must have only one symbol (i.e. no context).

<comment><USER3> Can you give me an example grammar to help visualize your statement? I can probably make a note or clarification. I think one other point I forgot to mention was that the production rule for the # directives would have to look something like

        include-directive:
            beginning-of-file # INCLUDE ...
            newline-from-previous-line # INCLUDE ...

Since 'beginning-of-file' isn't really something you can reduce to a token I justified that it would be context sensitive.

<comment><USER4> FWIW, I haven't thought too much about the case of the preprocessor, but this series of blog posts might help:

[http://trevorjim.com/how-to-prove-that-a-programming- languag...](http://trevorjim.com/how-to-prove-that-a-programming-language-is- context-free/)

My initial thoughts are that the property of being context-free only refers to a parser, not to the lexer. A lexer can be line-oriented, as mentioned.

The blog post mentions the lexer issue. The definition of a context-free language is fuzzy because you could have an infinitely powerful lexer, but he gives a precise definition.

<comment><USER2> In the strictest sense, "context-free" applies to either a grammar or a language. A language is context-free if there exists a context-free grammar for it, but there might be several grammars for the same language.

The lexical syntax is usually a "regular language" or quite close to one, this includes C. All regular languages are also context-free, the set of regular languages is a strict subset of the context-free languages. Regular languages can be parsed using regular expressions.

And again, there's nothing wrong with being line-oriented. That's not "more powerful" in any sense of the term. Recognizing newlines, SOF, EOF, etc. are really simple things (in the language hierarchy sense) that you can do in regular expressions without using any extensions that make them non-regular (like backreferences), therefore they can be converted to a context-free grammar.

Commonly, a programming language will have regular expressions for its lexer and a context-free grammar for its parser. Since the lexer is technically also context-free, it's possible to combine the lexer and parser into a single stage, but this is a bad idea for various software engineering reasons.

Some older languages have context-free parsers, like C, whose grammar is not context-free (that's not the same as "context-sensitive" which is a particular technical term). One major reason C's grammar is not context-free because it has to distinguish between typedefs and other identifiers.

Of course, a language as a whole is almost never context-free, but we usually use "context-free" to mean that the parser and lexer are context-free.

<comment><USER4> I don't think most languages in widespread use have lexers that are regular. Here the same author gives the example of Python's indentation requiring a stack: [http://trevorjim.com/python-is-not-context- free/](http://trevorjim.com/python-is-not-context-free/)

Also Haskell: [http://trevorjim.com/haskell-is-not-context- free/](http://trevorjim.com/haskell-is-not-context-free/)

I'm pretty sure in JavaScript that the /s+/ regex syntax can't be recognized with a regular language. Perl is of course insane -- it's not even statically parseable [1]. Shell isn't context-free.

The theme of this set of posts is that most languages used in practice aren't expressible with CFGs, and I agree. I didn't prove it but he shows how you would prove it.

[1] [http://www.oilshell.org/blog/2016/10/20.html](http://www.oilshell.org/blog/2016/10/20.html) (see the end of this post for links about C++, Perl, Make)

</comment></comment></comment></comment></comment><comment><USER5> > The C99 standard is about 500 pages, but only 19 of them are dedicated to > describing how the C preprocessor should work

IMHO This is not a mistake. This is a subtle indication about how much you should be doing with the C preprocessor.

People who try to do crazy clever tricks with the preprocessor are usually just creating a huge problem for themselves down the road, especially when porting over to a different OS or compiler.

If you're considering doing complex metaprogramming with the preprocessor you need to step back and reconsider your approach and ask yourself who is going to maintain it once you've moved on.

<comment><USER6> You don't need to get into "complex metaprogramming" to hit preprocessor bugs in many implementations. I've been finding c preprocessor bugs to iron out in glslang over the course of more than a year, and many of them are triggered perfectly reasonable typos.

The C preprocessor has just enough power for most of what it exists for (smoothing over build-time oddities, code which should/must be manually inlined with a macro to perform as desired).

Yes, you can abuse it and produce Bournegol, but there are many decent reasons to use most features of the C preprocessor, and the way it is defined is largely ergonomic, aside from the whitespace gotchas around function macros.

Robert is fully entitled to lament the process of implementing the preprocessor. Far be it from me to disagree. However, none of these examples seem weird if you just follow the intended implementation pattern: execute each step separately (at least as a model of behaviour) and you will have the desired result.

Even the "let me destroy your world with this example" example is straightforward as long as you follow the process.

-2: Digraphs and trigraphs are expanded

-1: Line continuations are collapsed

0: Comments are removed or ignored

1\. A macro is defined, `foo` is `<stdio.h>`

2\. The first non-whitespace character of a line is #

3\. The first non-whitespace character, and the contiguous non-whitespace characters form "include", followed by a macro expansion token, `foo` which we expand to `<stdio.h>`

4\. Splice in the included file, and continue preprocessing

5\. We're done, really, it was quite straightforward.

I think Robert's pain and confusion rests solely on his desire to define C as a context free grammar, when C parsers are really character-oriented state machines.

</comment></comment><comment><USER7> The most interesting things about C preprocessor is compile-time zero-overhead tuples and variadic macro overloading. e.g you can pass (a,b,c) as single argument to function(a) macros and selectively alter the tuple members and perform clever tricks which look like lisp code blocks unrolled at compile time(visible with gcc -E). Boost preprocessor and Order use it to create very powerful abstractions. see [http://www.boost.org/doc/libs/1_64_0/libs/preprocessor/doc/i...](http://www.boost.org/doc/libs/1_64_0/libs/preprocessor/doc/index.html) [https://github.com/rofl0r/order-pp](https://github.com/rofl0r/order-pp)

Variadic overloading of function macros is technique from [http://stackoverflow.com/questions/11761703/overloading- macr...](http://stackoverflow.com/questions/11761703/overloading-macro-on- number-of-arguments) combined with _Generic which overloads by type. It allows things like print("abc",1.2,3) to transform into printf("%s","abc"),printf("%f",1.2),printf("%d",3) without any overhead in the generated code.

see [https://www.reddit.com/r/frozenvoid/wiki/voidh](https://www.reddit.com/r/frozenvoid/wiki/voidh) Edit: and the tuple members are just symbolic tokens, they can contain anything from code to nested tuple trees. (code can be encapsulated in [https://gcc.gnu.org/onlinedocs/gcc/Statement- Exprs.html](https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html))

</comment><comment><USER8> I once started experimenting with (GNU) C macros: [https://gist.github.com/machuidel/d7cc099ddc4970c6ddf4](https://gist.github.com/machuidel/d7cc099ddc4970c6ddf4)

It became an abomination consisting out of many C-preprocessor hacks and impossible to debug. I never put it online (and I never will).

In the end if you want to use C at a more abstract level you may as well use Nim (not C, but it compiles to C89), C++ (of course) or write your own code generator (using libclang with annotations for ex.).

<comment><USER7> D mixin templates/mixins are another alternative: You can include arbitrary strings from functions running at compile time. Theoretically they're more powerful than C macros, but type safety(template parameters) makes some constructs awkward - unless you create and parse strings as tokens manually(basically reading/writing many strings to achieve what C preprocessor does with symbolic token composition). [https://dlang.org/mixin.html](https://dlang.org/mixin.html) [https://dlang.org/spec/template-mixin.html](https://dlang.org/spec/template- mixin.html) Templates can also include mixins: template liter(String s){mixin(s);}

</comment></comment><comment><USER9> [The scandal isn't that we're still using it?]

I actually used the fact that:

        #define return(r) ...

only expands for:

        return (something);

and not for:

        return something;

in a (non-serious non-production) program I wrote. I felt slightly dirty, but it made sense in the context -- tracking stack frames in order to do precise garbage collection of C code.

<comment><USER10> That sounds interesting. Any links or a further description?

<comment><USER9> Not anything released yet, but the idea is not new. I stole it from OCaml (possibly it came from elsewhere before that): [https://caml.inria.fr/pub/docs/manual- ocaml/intfc.html#sec42...](https://caml.inria.fr/pub/docs/manual- ocaml/intfc.html#sec423)

<comment><USER10> Ah, I was thinking it might be a more complex series of tricks to integrate GC more easily with C. For instance, redefining some C keywords, like 'return', to inject a prologue for freeing tagged locals or something.

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

</comment><comment><USER12> Well I like it because of all the things you can DO with it, not for all the things you can do wrong with it.

</comment><comment><USER13> For better or worse, I wrote [https://github.com/alpha123/cpplib](https://github.com/alpha123/cpplib) which is actually used in a commercial product.

The C preprocessor can be remarkably useful for metaprogramming.</comment>


Facebook Acquires Glancee - <AUTHOR> http://www.pcmag.com/article2/0,2817,2404024,00.asp

<comment><USER2> Looks like it was a clone of Glympse.

I'd be willing to bet these guys specifically cloned Glympse</comment>


Shady Harvard Puzzle Facebook App Disassembled - <AUTHOR> http://www.ianlewis.org/en/shady-harvard-puzzle-facebook-app-disassembled

<comment><USER2> So what was the answer? My guess is "A Riddle"</comment>


Should large(r) cooperations avoid using Node.js for back ends? - <AUTHOR> There seems that notion that node.js makes it easier for frontend developers to contribute to backends.
And since they are more likely to not take all of concerns of a backend into account, node.js should be avoided.
Do you think using a different language as barrier of entry like i.e. python or go will help ?
Do you think that node.js community is actually on average less senior than the python or the go community ? <comment><USER2> I think there are a lot of misconceptions about nodejs in this with people who are not familiar with it, i belive it will always be easy for any backend developer to work with node than a front end dev, as there are database interaction, networking concepts, api development and many more things that a front end dev has never worked with. And since when is other people learning to new tech and making progress a bad thing.

</comment><comment><USER3> Node is already huge in the enterprise, and it's growing really fast. I don't think you're going to be very successful in any attempt to change that.

Instead of trying to come up with ways to exclude people, why not put effort into training your peers? Everyone starts somewhere.

Finally, are you prepared to learn from these people that you look down on? If you aren't, you might wake up one day and discover that your skills are not as useful as they once were.</comment>


'My boss lets me set my own salary' - <AUTHOR> https://www.bbc.co.uk/news/business-49677147 <comment><USER2> One of the companies in the article, GrantTree, is run by swombat ([https://news.ycombinator.com/user?id=swombat](https://news.ycombinator.com/user?id=swombat)). It's an interesting perk. I can see it being _amazing_ for staff retention, but only if your staff are the sort of people who really want to work at the company. It definitely wouldn't work for a lot of companies.

<comment><USER3> You are absolutely right. I work at GrantTtree and hiring for purpose is definitely a fundamental part of the equation. That and trusting your colleagues and keeping an honest feedback-friendly environment. It's certainly not as simple as one might think.

</comment></comment><comment><USER4> I wonder how the effect would be. It reminds me the "unlimited vacation" policy of some startups in USA that failed badly

<comment><USER3> That's a very interesting question. I feel like there will always be people who feel peer pressure more than others, but it'a not just that. The puritan work ethics also have a strong impact on some people to a subconscious level. All I can say is thay the more people do it, the less problematic it becomes. But it does require a good level of self-awareness.</comment></comment>


Tesla: The Origin Story - <AUTHOR> http://www.businessinsider.com/tesla-the-origin-story-2014-10 <comment><USER2> Origin story? Maybe. The coverage up through 2008 was good, but then the author pretty much shortcut the rest of the article. They made no mention of the immense financial difficulties Tesla faced in the 2007-2008 era, which is of significant historical importance. The article completely omitted the actual shipment and reception of the Roadster, and the subsequent development of the Model S.

Nonetheless, it was nice to read about the very early history of the company, some of which was unknown to me. I note the parallels to Steve Jobs in this story, and how effective Tesla's PR machine is -- Musk really likes being portrayed as the founder.

</comment><comment><USER3> Not a good start. Second and third sentences in:

> The last successful American car startup was founded 111 years ago. It's > called Ford.

This isn't remotely true. Ford was founded in 1903. GM was founded in 1908. AMC was a merger of two companies, one founded in 1937 and the other in 1909. Chrysler was founded in 1925. And that's just the big four.

<comment><USER4> Reading the Wikipedia article, this statement may be based on the fact that Ford was the last American car company to IPO (in 1956) making it the last one to count as a startup.

<comment><USER3> I don't think so, as 1956 wasn't "111 years ago".

<comment><USER5> It says it was _founded_ 111 years ago, not that it IPOed 111 years ago.

</comment></comment></comment></comment><comment><USER6> I don't see why Elon isn't more direct about addressing the company's early history. Why not say "I had to ditch the original founder of Tesla for various reasons, then work really hard to get our first car out at a quality level requisite for the future success of the firm. That's what happens when you lose the confidence of the board and your biggest investor, tough luck".

The article is quite interesting overall. However, it is very Eberhard centric and does a poor job of detailing the substantial challenges Elon faced getting the first car successfully manufactured, as well as the financial challenges and the US Govt. loan, and all sorts of other fascinating details. A book, perhaps, would work better than an article.

</comment><comment><USER7> for anyone else wanting to read Elon Musk's story in more depth, I can't recommend "The Engineer" by Erik Nordeus enough. He basically compiled titbits of information from various interviews and articles and reconstructed the timeline of Elon Musk's public life into a great biography.

[https://leanpub.com/theengineer](https://leanpub.com/theengineer)

<comment><USER8> Thank you!

/The author

<comment><USER9> Thank you for creating - looks like an interesting read. Just purchased.

</comment></comment></comment><comment><USER10> Awful lot of negative comments here. I thoroughly enjoyed the article. Was it biased? Everything is. But it explained a bunch of history that I didn't know in narrative form, which I appreciate.

</comment><comment><USER11> Great article, But didn't cover the launch of roadster. The whole article was buidling for that ending. Still I wasn't aware of most of the history so was a nice read.

</comment><comment><USER12> I feel so sad, I worked at an electric car company in the beginning of the 2000's (as a summer job), and we all knew that those cars were mechanically far better than the combustion engine ones. You had constant power from 500 to 10000RPM, they broke some differential gears during R&D.

But the cars makers canned the projects one after the others. It's the telecom industry who paid for the battery R&D in the end.

</comment><comment><USER13> Wait - did Business Insider do original reporting?

I think that's one of the signs of the apocalypse.

<comment><USER14> I was thinking the same. The first thing I do any time I open a BI link (on that rare occasion), the first thing I do is check if they have listed a source, and go read the source.

</comment></comment><comment><USER15> It's interesting to contrast Tesla and Fisker.

<comment><USER16> Even more interesting to see the links between the two companies.

The Wikipedia page on the model S says it's designed by one Franz von Holzhausen and doesn't mention Fisker at all but on the page of Fisker Automotive you read this:

"On April 14, 2008, Tesla Motors filed a lawsuit against Fisker Automotive, alleging they stole Tesla's technology and are using it to develop their own hybrid car, the Fisker Karma, which was announced at the North American International Auto Show in January 2008. Tesla's suit claims that the design work done for the Model S by Fisker Coachbuild was substandard, and that Fisker diverted its best ideas to the Karma. In early 2009 the suit was settled in Fisker's favor and Tesla was ordered to pay Fisker more than US$1.1 million in legal fees."

I wonder how much of the Fisker design is still present in the model S or if they tossed it all and redid the whole thing. When I first saw the Model S and the Karma side-by-side I thought 'wow, those two look quite similar in a way' with the Model S the clear winner (the Fisker looks kind of odd up close).

</comment></comment><comment><USER17> Article says, "On April 23, 2003, Tarpenning bought the domain name Teslamotors.com", but whois creation date shows 2003-04-03. Is that possible?

</comment><comment><USER18> Ouch, the bias is dripping from this article. Choice of pictures and wording is quite provocative.

</comment><comment><USER19> I don't think I will ever understand how a Business Insider article can get 45 points.

<comment><USER20> Because it mentions Tesla. Spend some time in /r/technology and you will see just how pervasive the Tesla love is amongst the technical community. There's nothing rational about it.

<comment><USER21> You're getting downvoted, but I think it's true.

<comment><USER22> The tech community often roots for the underdog v/s the Goliaths. Just look at the MS/IBM hate; and the love for Apple when it was struggling earlier this century (of course that has changed now)

</comment></comment></comment></comment><comment><USER23> The more you read about great companies the more you realize that this is the key :

      Eberhard realised that Musk was the first guy he had met
      who shared his vision for electric cars: Make a vastly
      superior car, not just a car that sucks less.

This is why Google won, and again with Gmail, why Facebook worked (compare it to the only "social networks" that preceeded it - dating sites and you'll see how it's vastly superior), and even before, why Microsoft won (visual basic being the truly superior product).

We also know that design-by-committee approach of large companies can only ever produce mediocre products. Low-risk mediocre products. Most or all of these are doomed. A lot of stuff is ready for complete disruption.

<comment><USER24> Could you elaborate please, what's the key? Partnership? Visionaries?

<comment><USER25> Vastly superior products. That's also why the iPhone was the first broadly successful smartphone. MS Windows was also at one point a vastly superior product.

<comment><USER26> This seems nearly tautological to me. Without knowing how to make a vastly superior product, and without knowing how to tell whether a product is vastly superior before testing it in the crucible of the market, this conveys no information.</comment></comment></comment></comment>


Six Apart: We Are Opening the Social Graph - <AUTHOR> http://www.sixapart.com/about/news/2007/09/were_opening_th.html <comment><USER2> This is good. The phrase "OpenID ... was successful" isn't the best thing to lead with, but their heart's in the right place.

</comment><comment><USER3> It's the only sensible strategy to compete with the likes of Facebook and the Google social network (whenever they finish building it and tying it together via RSS). People only have time/interest in being a part of so many social networks before they won't bother even if "the application built on the new one is really cool."

</comment><comment><USER4> Hmmn, someone's bitter about Brad Fitzpatrick having left...</comment>


36 million miles of space dust disappearslike magic. - <AUTHOR> http://spaceindustrynews.com/space-dust-magically-disappears/

<comment><USER2> I wish articles like these wouldn't use these cartoonish "70s sci fi" illustrations. It makes it seem like the real science is too abstract or shaky to demonstrate. I really think that people likely to read Space Industry News could swallow a few awkward nerdy visualizations. For those audiences, dodge- and-burned asteroids feel patronizing.

<comment><USER3> Welcome to the debased state of science journalism. Anyone with half a brain should feel completely insulted by this b.s.</comment></comment>


Signal down worldwide for 2hrs - <AUTHOR> https://github.com/signalapp/Signal-Android/issues/7460 <comment><AUTHOR> No explanation yet as to the cause, other than to say via Twitter: "The outage was not caused by a DDoS or any other type of attack."

[https://twitter.com/signalapp/status/970781128331214849](https://twitter.com/signalapp/status/970781128331214849)</comment>


An overview of gradient descent optimization algorithms - <AUTHOR> https://arxiv.org/abs/1609.04747 <comment><USER2> It isn't mentioned in the abstract, but this seems to be more of an overview of ML-specific notions of gradient descent, where batch processing is possible due to needing to leverage gradients of a fixed prediction architecture over a large set of training data, with respect to tunable weights.

So each of those training points represents a sort of separable or parallelizable piece of the whole processes, giving you a ton of freedom in how you actually execute the gradient stepping (with one training point, several of them, or all of them). As I understand it, stochasticity in this process interestingly seems to add enough "noise" that local minima seem to be avoided in many cases.

In more general applications of non-linear gradient-based optimization (say for optimizing parametric models in physical engineering), this doesn't necessarily come into play.

<comment><USER3> Do you have any sense of whether tricks like momentum which afaik came out of improving SGD for neural network training have found application in other arenas where batching is less reasonable?

<comment><USER2> I think there is room to exchange ideas between the nonlinear programming and ML communities for sure.

Specifically for momentum, if I understand it right it's a particular way of perturbing step size and gradient steps to prevent oscillation. There are some other good examples of this used by many gradient-descent optimizers. For example:

[https://www.cs.cmu.edu/~ggordon/10725-F12/scribes/10725_Lect...](https://www.cs.cmu.edu/~ggordon/10725-F12/scribes/10725_Lecture5.pdf)

There's part of me that wonders if one interesting way forward for deep learning is a minibatch form of BFGS or SNOPT.

</comment></comment></comment><comment><USER4> Here[1] is an article describing the same, written by the author himself.

[1]: [http://ruder.io/optimizing-gradient- descent/index.html](http://ruder.io/optimizing-gradient-descent/index.html)

</comment><comment><USER5> Stupid Q: Assuming "gradient descent" is roughly similar to the classical "steepest descent" optimization algorithm (???), why aren't deep learning researchers looking into other more advanced algorithms from classical non- linear optimization theory. Like, say, (preconditioned) conjugate gradient, or quasi-Newton methods such as BFGS?

</comment><comment><USER6> SGD > adaptive, according to this:

[https://people.eecs.berkeley.edu/~brecht/papers/17.WilEtAl.A...](https://people.eecs.berkeley.edu/~brecht/papers/17.WilEtAl.Ada.pdf)</comment>


Dead Man's Switch - <AUTHOR> https://www.deadmansswitch.net/ <comment><USER3> This same website gets posted once in a while and it drives me crazy.

Do not use this service. With less than 60 seconds of looking, you can hijack people's deadmanswitch accounts with a simple CSRF on the email change API.

If you have a "high value secret" and you are a normal person, lawyers work pretty well. If you have a "high value secret" and you're Ed Snow, something like this site is not a solution you should use because it will get you killed. Nobody has a use for this...

<comment><USER4> Whoops, thanks for that, will fix. The service is pretty old, but I'm still surprised I didn't add the CSRF fix on one of the rewrites.

That said, tens of thousands of users apparently have a use for this. I'd imagine it's mostly "last goodbyes" type of stuff, also many users email me saying they want something to send "something happened to me, please come so my dog won't starve".

"Millionaire with assets" and "Ed Snowden" aren't the only two possibilities.

<comment><USER5> > "last goodbyes" ... "Millionaire with assets" and "Ed Snowden" aren't the > only two possibilities.

Suicidal tendencies, then? While you are applying the "fix" may want to add a link to suicide prevention resources.

<comment><USER6> >Suicidal tendencies, then?

No, it might surprise you to learn that all humans eventually die. Some of them even have families they want to send 'death-bed' notes to.

<comment><USER7> > No, it might surprise you to learn that all humans eventually die.

This seems uselessly snarky, especially since StavrosK (who I assume is the developer, based on other posts) gave a polite and snark-free response already:

> That's actually probably a good idea, I will add that, thanks.

([https://news.ycombinator.com/item?id=12630400](https://news.ycombinator.com/item?id=12630400)).

<comment><USER4> It's okay, I don't mind. I've added the notice, too, and am fixing the CSRF problem now.

</comment></comment></comment></comment></comment></comment><comment><USER8> It's worth noting that both Google and Facebook provide ways of handling your account after you die:

Google Inactive Account Manager: [https://support.google.com/accounts/answer/3036546](https://support.google.com/accounts/answer/3036546)

Facebook Legacy Contact / Memorialization: [https://www.facebook.com/help/1568013990080948](https://www.facebook.com/help/1568013990080948)

<comment><USER9> This is both a lot more reliable and more straightforward to both set up and use.

</comment></comment><comment><USER10> Yikes, given the sorts of uses this would be put to, it seems like the definition of a "high-value target".

I would be terrified of running a site like this unless I had a lot of experience with resisting DoS and state-sponsored attackers.

<comment><USER4> It's been okay so far, but yes, I definitely urge everyone to PGP-encrypt their messages before adding them to the service. No matter how much encryption you put in the model layer, the service still needs to be able to read the plaintext to send it at some point...

<comment><USER11> So, how do you suggest encrypting the data to be sent, while still allowing for the purpose of the service, which is to distribute the data to people later on? The best I can think of off the top of my head is a dedicated PGP key, and two DMS services, one with the data, one with the key. Otherwise you're always at least exposing the data to the DMS service.

<comment><USER4> I was actually thinking more the standard model, where you encrypt the email to a person's PGP key. This only works if the other person has a PGP key, though. It's the usual security <-> convenience tradeoff, unfortunately.

</comment></comment></comment></comment><comment><USER12> Interesting project! I had a similar idea- "My Social Death". When you died, it would post to your Facebook, Twitter, etc. Thought of it when a few friends died and I saw many others changing their profile pictures and continuing to bring up how close they were. People grieve in their own way but it rubbed me the wrong way and I started thinking of how you could control the message when you died. I would love to post a "I had a good life, don't be sad for me" type of message. But verifying death is certainly tricky...

My verification idea was the self emails, but also a few friends would have to verify (or they could initiate). That way if you lost access to your email, you could avoid a false positive.

<comment><USER13> I love this idea.

First, your point about controlling the message when you pass is TERRIFIC. How many of us have seen opportunistic acquaintances take over the memorial of a dead loved one. It really, really sucks, especially when the acquaintance colors everything through their own beliefs, and those beliefs contradict the beliefs/opinions of the deceased.

Then you gotta think about the potential to send individualized messages to your loved ones. Damn that would be touching.

Plus, what about stuff like Mark Twain's journals. Supposedly he had written much that he feared to publish because it was too incendiary. He thought it'd be ok for it to be published after his death. However his estate chose to keep it private.

Next you can imagine the fun you could have planning your account to 'haunt' people you didn't want to say nice stuff to.

Good shit

</comment></comment><comment><USER14> At first I thought this was Dead Man's Snitch[1], a service based on the same concept but used to alert you when cron jobs fail to execute. A pretty valuable part of my toolbox on every project.

1\. [https://deadmanssnitch.com](https://deadmanssnitch.com)

<comment><USER4> I'm still kicking myself for not thinking of that first! Dead Man's Snitch is a fantastic service.

</comment></comment><comment><USER15> I have at least one datapoint to suggest that people are looking for this kind of thing.

I run a service, Cronitor, essentially a dead man's switch for jobs, heartbeats, etc. Doing some analysis on notification method preferences (Email is top, followed by Slack) I noticed a webhook that will hit a url that ended with send_secrets.php if the creator doesn't ping at least once every day.

No alerts had yet been sent so the secrets seem to be safe. I added a todo for a couple more test cases around alert sending -- I'd hate to ship a bug that accidentally sends whatever the heck is in that file. I would suspect the creators of this service will feel that same pressure soon.

<comment><USER4> > I would suspect the creators of this service will feel that same pressure > soon.

The service has been running for eight or so years now, and the safeguards against this have worked pretty well, but yeah, every change is a chance for something to go wrong. I have extensive tests for the sending code and the logic to check whether it's time to send, though.

<comment><USER15> I would imagine you have a low number of alerts sent every day, even after 8 years? Or do you have enough noise from trialers that it would prohibit a manual review step? Early on we would basically get cc'd on every alert sent -- had to stop that by the 3rd month because jobs/services/etc actually fail _all the fricken time_.

<comment><USER4> I did have that in the beginning, I stopped it when erroneous emails fell to zero. Extensive testing helped greatly with that, and the service had barely any false positives even in the beginning.

</comment></comment></comment></comment><comment><USER16> To EVERYONE screaming at how insecure this service is: PGP. I've ensured key members of my family have PGP keys via keybase.io, and stored only a signed and encrypted message on the servers.

I've used this site for years now and I can firsthand tell you how awesome it is. I once accidentally triggered my death when I dropped out of contact for a few months, but otherwise, it's amazing to know that even if I die, I can from beyond the grave, I can set in motion an elaborate chain of events that will end up with my family possessing all my digital assets (including about half a bitcoin), people whose digital assets I manage will receive full control back, and MOST importantly: my best friend will delete the porn on my computer in time, and only then surrender my passphrase to my family.

<comment><USER4> It's great to hear you like the service, thank you! Protip, though: encrypt your porn :P

</comment></comment><comment><USER17> If I was an immoral criminal minded asshole, I'd probably create a service like this to get my hands on as many juicy secrets as possible and see what knowledge I could get. Maybe I'll find out some hidden business info that I could make money on, or maybe I could get leverage over on somebody to threaten and blackmail them.

I'm not saying that this is that site's intent, but I'd be cautious about trusting them with anything particularly juicy.

</comment><comment><USER18> This would be a brilliant long game phishing attack. You have regular emails with links arriving that people think they have to click or bad things will happen. Not saying at all that's what this is, just that the thought popped into my mind.

</comment><comment><USER19> Great idea!

I'd like to see an answer to "How will you ensure the continued operation of this service over N years?" on the help page though.

<comment><USER4> I get that a lot. The answer is "if the service goes down, I'll send you an email well in advance so you can switch. If you die before that, well, your emails will have already gone out, so you don't have anything to lose."

<comment><USER20> So presumably you have an automated dead man's switch built into the service? Do you also have arrangements for continuation of the service if you 'get hit by a bus'?

</comment></comment></comment><comment><USER21> I'm a bit worried by the reliance on email to validate aliveness. If something were to ...happen... (ominous music playing in the background) it's possible that such an entity could gain access to my inbox, allowing them to sidestep the DMS entirely, perhaps even gain access to its contents?

Ideally this would require two or three separate methods to verify you're still alive. Or some form of challenge/response relying on at least two different mediums/communication networks/devices.

<comment><USER22> The worst thing for me is if their emails start going through my spam folder-- I check it once in a while, but when my life gets hectic it's the first thing that gets dropped.

<comment><USER4> That is a concern, but it's trivial to set up a rule to whitelist firstname.lastname@example.com.

</comment></comment></comment><comment><USER23> This is a really great idea, with a really poor execution.

I'm just a regular guy, but the messages and details that I would leave in a service like this are too sensitive to be put on someone else's server for a period of years. (Maybe I'm just too private in this age of social networks).

We really need a PGP like solution for the masses. On that note, I wonder why someone like Mozilla doesn't take this on and push for human friendly client certificate authentication.

<comment><USER24> > We really need a PGP like solution for the masses.

How would that solve the issue of putting the secret on someone else's server and guaranteeing that it'll be available after death only? They'd have to have a key to decrypt to release it (in any useful meaning of the word) then you're dealing with storing the key and the encrypted secret. You still have to ensure that the decrypt key will get released on your death but not before and used to unlock your other secret.

<comment><USER23> Assuming we restrict the solution to this problem space. Since I trust the service to send the message, then I trust them as well to generate the encrypted package and communicate the passphrase needed to decrypt. I trust them enough to not keep that passphrase around.

Then the workflow would be something like the service sending an email to each intended recipient with a short message saying keep this message saved it includes a passphrase that you will need later. Then when the switch fires another email is sent asking the recipient to provide the passphrase. The service will then decrypt the message with the passphrase.

I know this still requires a lot of trust, but it at least protects the data at rest.

<comment><USER24> That at least protects it on the server but the secret sitting in the email is pretty insecure since the generated decryption key is only as strong as the least secure recipients security.

</comment></comment></comment></comment><comment><USER25> I like this idea. How do you ensure that you'll be around longer than I will?

<comment><USER22> Clearly, you need to create your own Dead Man Switch's Dead Man Switch.

</comment></comment><comment><USER26> I've been thinking about something like this for a long time, but I've never come to a solution where I'm fully comfortable with the technology to fully trust it.

There's too many "What if?"s. The biggest one being: What if their system glitches and mistakenly sends out emails even though I've been checking in?

What if I lose access to my email account? What if I end up in jail (regardless of reason) and can't hit the switch? What if they get a subpoena for the information contained within the emails? What if the service goes down? I'm under 30 - it's unlikely anything like this will be around for 50+ years.

To have a fully safe and secure Dead Man's Switch you would need more than just one layer of confirmation, and more than one layer of failsafes.

My thought so far is:

A service such as this one, except instead of an email with your secrets, it would simply release private key to certain key individuals. In said email would be only the key, and nothing else. This would have to be somewhat tech- savvy individuals that would know the significance of the key upon getting it. The email should come from my own personal address.

In my will I would entrust a different set of individuals (immediate family, etc) to one or more lockboxes contained an encrypted drive (HDD, SSD, flash drive.. something resilient.. maybe even the entire device.. maybe all of the above to protect against obsolescence.. ). The recipients of the first email would have to get in contact with these folks and mutually agree to decrypt the data on the drives.

If the emails are sent by mistake, then all I have to do is seek out my lockboxes and encrypt with a new key. The people who got the key will probably be asking "wtf is this?" about. Had I been dead, them seeing an email from my personal address with a private key would elicit a much different response.

Unfortunately this plan still relies on some technology to continuously log that I hit a button, which I don't like. I could misplace emails, I could lose access to my domain, if I do it via SMS, I could close my cell phone number... list goes on.

The only thing I can think of that doesn't involve another piece of technology is trusting the private key to a person (or organization) who is impartial and bound to secrecy to only divulge the key upon a copy of your death certificate. Lawyer perhaps?

Come to think of it, this could be a really cool add-on service to a life insurance policy. Instead of just cash, your beneficiaries get cash + vaulted information.

<comment><USER20> I thought this was a standard service as an add on to having a will held by a solicitor. That is passing on documents or a key to a safe-deposit box?

</comment></comment><comment><USER27> I've been thinking about this on-and-off for a while now. I don't want to entrust my secrets with any single entity; I want a cryptographic solution.

A couple ideas I have considered:

\- Using a secret sharing protocol to split a key into N pieces for people you trust. This would be relatively simple, but there's the risk that they might be hard to get into contact with, or might have come into harm's way themselves. A threshold scheme can be used to allow N<M people to reconstruct the key. This is vulnerable to collusion. To prevent compromise of individuals in a targeted attack, the keys could be stored on smart cards. Also vulnerable to hardware failure.

\- Unparallelizable time lock / time release crypto. The problem is, this needs to be able to be decrypted in a reasonable amount of time after my death. But if that's the case, then any bad actor could decrypt it given enough time. One solution is to embed the private key and program in an HSM, and use enough rounds that it will take, say, one week for the HSM to brute force. I could reset it daily, and connect it to my UPS. Should I die, I wouldn't be there to reset it, and it would release the private key. The problem there is, should I ever get held up for any reason, it'd be released. The idea sounds cool, but I'm not sure it'd work very well. Also, what if the hardware becomes damaged after my death? Or a violent criminal breaks into my house and steals the HSM with everything else indiscriminately?

Both schemes could also be used in parallel---the HSM key could be absolutely required in conjunction with everything else. If it is compromised, I generate new keys and redistribute them. This all requires more thought.

The scheme needs to be very unlikely to fail. If I die, I want it to include private keys for my disk encryption, select account passwords, etc so that my wife can access the information she needs, or would find valuable. I would also likely sign (cryptographically with my PGP key) a document that states that I have indeed died, to send to others.

<comment><USER28> Just PGP encrypt message with recipient's public key..

<comment><USER27> "I don't want to trust my secrets with any single entity"

As in, I don't want to use this service. Or any other.

</comment></comment></comment><comment><USER29> Doesn't google already offer a very similar service built straight into gmail ?

<comment><USER30> Yes, Inactive Account Manager. [https://support.google.com/accounts/answer/3036546?hl=en](https://support.google.com/accounts/answer/3036546?hl=en)

The best part is that it goes based on your Google Account activity, which, for most people, consists of searches, Android/iOS use, etc -- not just clicking a link.

</comment></comment><comment><USER31> I was building a similar product at deadmansswit.ch for a while, but gave up. I always thought the privacy-leaning Swiss aspect of the URL was fun, and I planned to have it run out of a DC in Switzerland.

I had more than email as the check-in transport, and the trigger would have delivered more than just email (upload files and videos to online services, post to Twitter, etc).

Anyway, the domain is free again if anyone wants it.

Edit: spoke too soon, it appears to have been taken by someone else.

</comment><comment><USER32> > Premium Price: $20/lifetime

That's so discriminatory to cats with their nine lives! :D

Seriously, that's a great site, and I love the one-time fee model.

<comment><USER4> Hey, cats keep wanting to send messages once per life, so it's actually pretty fair!

</comment></comment><comment><USER33> A great idea. When my girlfriend got sick and immunent death was a realistic possibility, she wrote down all her usernames and passwords on a piece of paper, which I then put in a drawer in my home office, only to look at when the worst happened.

It struck me at the time as being insecure but the low tech solution worked.

Perhaps this site would have been a better solution.

</comment><comment><USER34> I had a similar idea to do this.

Is there any guarantee that if "bad things happen" to the author(s) of this project, the emails will live on and will be sent?

What about using Ethereum and the likes for these services?

<comment><USER35> How would this work on Ethereum? Contracts require money to run, right?

<comment><USER34> Hence my question. I have to read the technical details of contracts and ethereum itself to see if it would be feasible. But if that money guaranteed that it was sent even after the company that provided the service ceased to exist, it would probably be worth it.

Of course that it depends on the amount of money needed..

</comment></comment></comment><comment><USER36> I've been using this service since shortly after I had an autoimmune attack that ate away a chunk of my nervous system about 8 years ago where I nearly died(technically, did kill me at one point for over a minute before they revived me). I went from being pretty much like you blokes, lost in the details of living without seriously thinking about dying...But i mean, who doesn't in their late 30s. It's easy to get tied up in your day to day concerns until those days start becoming distressingly short. Thankfully, I survived that, and the five years of rehabilitation it's taken to get me back to some shade approximating "normal", though i'm still very functionally and impaired and will never again be what I was...But such is life. Life is 10% what happens to you, 10% the available choices of your circumstances, and 80% how you CHOOSE to feel about it. All that being said, it's important to remember, the only people who know how and where they're going to die are suicides and people on death's row. The rest of us don't. Having lost many dear freinds and family over the years, I can tell you all unequivocally you should consider what you'd want to say to your friends, your family, even your most cherished rivals....Because statistically, at least one in one in three of every one reading this will die unexpectedly(heart disease, car wreck, lingering crotch rot from a unsanitary toilet seat, et al). Another third of you will get a terminal diagnosis only a few months before you expire because you put off "having that thing looked at like you've been meaning to" until it was too late.

I want that to sink in to all of you. Two of three of you wont have time for carefully crafting what you want to say, or to whom...Because you'll either BE dead, or WILL be shortly. And what i'll bet most of you want to say isn't about where you buried the treasure chest of Al Capone, or that you're the secret love child of Ronald Regan and Janet Jackson...It's that you love them, that you treasure this and that shared memory with them, and that you wish for them to remember you a particular way, or perform a certain ritual in your memory and honor, should they choose. Sure, this database wouldn't be hard to hack. What's in there is almost completely useless to anyone other than their loved ones. can you imagine how depressing it would be to read a hundred thousand dead people's communiques to snag the one juicy bit about some senator being the illegitimate son of Prince and Madonna? Yikes! All that being said, I've spent quite some time thinking on this subject, and the answer I keep coming back to on the "Verifying you're dead" problem I think should be handled by examination of the customers data footprint in some sort of routine way. If any of you have ever done data analytics or doxying, you'll know that there are some distinct signs that start to appear when your subject focus has died or dropped deeply off the grid, even after a few days. It seems to me that such qualities could be mathematically modeled into a set of software scripts, and that tied to the trigger. With a failsafe of primary and secondary inquiry designated by the client. I have a few other ideas along these lines that prudence dictates I should keep to myself until it can be developed and patented properly. If any of you would like to work with me on such a project, please contact me at email@example.com

</comment><comment><USER37> A really valuable service to offer, with a great simple pricing model.

<comment><USER38> Until they're acquired and shutdown by google in the middle of my abduction.

<comment><USER4> Haha, if Google wanted this, they would have talked to me in the eight years it's been running.

<comment><USER11> Not to mention, I imagine greater than 90% of the customers would jump ship immediately. People have a perception of Google as gobbling up all their info and learning all their personal information, so I imagine quite a lot of them would be worried that Google would learn whatever secret they don't want exposed yet.

</comment></comment></comment></comment><comment><USER39> Get you killed? Don't be so melodramatic.

This implementation is a bad idea to use because of the aforementioned security smell.

Another implementation would have to solve the problem of how to ensure message security while still being able to deliver the message at the right time.

The "right" answer for something like this is as you said, lawyers, but "get you killed" is... overly dramatic. Snowden is, after all, still alive.

<comment><USER40> Stop. Broken privacy tools _have_ gotten people tortured and killed. Just because you can't imagine it happening to white dudes in the US and western Europe doesn't mean it isn't the norm _pretty much everywhere else_.

You were fine before your "Snowden is still alive" thing. I don't have an opinion about whether Stavros's site is a serious privacy application. Maybe it isn't. But other manifestly unqualified people have tried to deliver privacy to people and failed catastrophically.

<comment><USER4> It is definitely _not_ a serious privacy application. It's meant for sending things like last goodbyes to loved ones, not state secrets. I will make this clearer on the front page, on a second read the "stored securely" part might be misread as "secure against the NSA" rather than "secured against a curious DB admin", thanks for the clarification.

<comment><USER41> I'd go pretty far in that direction, were I running this service. Something along the lines of "hey, I do my best, but anything that'd significantly impact anyone's life if it were disclosed accidentally or compromised is best stored offline, with information on how to find it being all that's actually set up to go out via my service." And maybe I wouldn't even be comfortable with that.

Actually, on further reflection, I wouldn't be comfortable running a service like this at all, for reasons amply detailed elsewhere in these comments - <USER2> short, it's a great way to paint a target on your chest for everybody from random scammers to state-level actors. I must admit I am considerably impressed by your courage in continuing to do so. Don't get me wrong - I think you must be a madman. But I can respect a very brave madman!

<comment><USER4> I added something here ([https://deadmansapphr.appspot.com/help/](https://deadmansapphr.appspot.com/help/)), hopefully it's clear enough, but let me know if you have any feedback. I would hate to have people thinking this is secure against the NSA or anything.

<comment><USER41> It's clear as far as it goes, but as I said before, I don't think it goes nearly far enough. It's not just that messages stored with your service aren't secure against state actors - messages stored with your service aren't secure against anyone with the nous to compromise the host(s) on which it runs. And I hope you'll forgive me for saying that, given that you managed to overlook trivial CSRF for a year in the application's request handling code, I'm not entirely sanguine that your host configuration is strongly secure against any, perhaps even most, non-state actors.

That's not something I like saying, and I can't imagine it's all that pleasant to hear, either. I wouldn't say it at all if I did not feel it necessary, and I feel it necessary precisely because there seems to be a severe mismatch here between the gravity of any potential compromise of your service and the measures taken to prevent such a compromise from occurring. You know a lot more about the nature and scope of those measures than I do, of course, and it's possible I'm underestimating them here. I do hope that's the case. If it is, please accept my apologies for having spoken harshly where doing so was unwarranted. If it isn't, I hope you'll attend to that situation as best you can without delay. If you're not sure, then for the sake of your users, I hope you'll bring in someone with the capability to evaluate and resolve whatever security issues exist, and do so with as little delay as possible.

In any case, you've (perhaps accidentally) put yourself in a position that encourages people to invest a great deal of trust in you, and it seems that many people have done so. Had I put myself in such a position, I would not be comfortable remaining in it if I could not be entirely confident I had either done everything within my power to fulfill that trust, or removed myself from that position without betraying the trust I'd found myself ultimately unable to fulfill. But that's just my own evaluation, and perhaps you feel differently.

</comment></comment></comment></comment></comment></comment><comment><USER42> [deleted]

<comment><USER43> These seem to have nothing to do with each other, and if you're trying to imply they stole the name then you should know "dead man's switch" is nowhere near an original term. [https://en.wikipedia.org/wiki/Dead_man%27s_switch](https://en.wikipedia.org/wiki/Dead_man%27s_switch)</comment></comment>