mdirolf

We're moving 8 domains over right now.

Sorry about that - we use Tumblr to host the blog and have had some issues before. I just converted to a pastebin for you, unfortunately didn't think to include any of the comments but here you go: http://pastebin.com/yHw7L0Fy

Yeah, I decided not to get into all of the options of each header. Partially because I was writing from a plane without wifi and partially because the response I was hoping for was "these things exist - I'll go read the docs on them".

That said, your points about X-Frame-Options and CSP are definitely important for usability. Maybe I'll update the post w/ some of those details.

Ha fair enough, and thanks! One problem with the CA system is that (as far as I understand) it really doesn't matter whether you choose a particularly secure CA or not - you're as vulnerable as the most vulnerable CA. That's why something like public-key pinning is important.

Good to know - thanks. More support is better, but the thing I really like about CSP is how it is still useful as a canary even with only partial browser support.

No problem - I definitely recommend reading the linked Mozilla docs on them.

Glad you enjoyed it.

Thanks!

We'll try to keep adding whatever information we can about our deployment. If you have specific questions just shoot us an email - they'll probably be good inspiration for future posts.

That's a great question, and to be honest it's a bit of a pain point so I probably should've talked about it in the post.

When developing a new M/R job from scratch I start by mirroring (at least part of) the data to a local database. Then I can iterate locally on the M/R using print() and printjson() to debug the map() and reduce() functions - those will print directly to the database log.

I tend to just embed the map() & reduce() functions as Python strings like you see in the post. I'm confident that there are better ways to handle this, though. One approach that can be interesting is to do development from the shell, that way you can write and debug the map() & reduce() in an actual JS environment. Once you're happy with them you can just drop them in as strings with the rest of your application code. Would love to hear how other people are approaching this stuff, too.

All of that said, I expect that the tooling here will improve over time.

1.8 has single server durability, but TBH I haven't had a chance to check it out in depth yet.

Exactly. The option of scaling out later is great, but the huge benefits for early stage projects are flexibility and ease of use.

still fleshing that out, but will probably be free for smaller use cases. also, it's @fiesta :)

Hi, fiesta.cc is me - working on the white-labeling stuff as we speak. Shoot me an email if you think you might want to try it. mike [at] corp.fiesta.cc

the defining feature of fiesta.cc (as opposed to posterous, etc) is that list names don't have to be unique - so anybody can make a new list called "family@fiesta.cc" without worrying about registering the name or running into collisions.

Right now messages aren't saved at all (for privacy reasons). In the future there will be optional (opt-in) archiving like yahoo/google groups has.

oops, thought that was handled properly. fixing now (if you don't want to wait you can change your name from the "Dashboard" page). Thanks for the heads up!

Thanks for the feedback! I was thinking of .cc as a feature, designed to evoke the act of CC'ing an address to create a list. Wasn't a decision made due to lack of seriousness or to cut costs, but maybe still needs rethinking if the CC connection isn't obvious...

this is exactly one of the ideas that I want to pursue!

Yeah, the other nice thing about this compared to librelist is that you can use any list name you want without worrying about conflicts (since lists are tied to the sender's address).

Yup, using MongoDB to store everything. I will definitely be doing a post discussing the architecture, etc. Follow @mdirolf or @fiesta and you'll see it when it pops up.

The short answer, though, is that I'm running a 3 node replica set. Each mailserver (right now there are 2) is running on one of those nodes.

Thanks! Yeah I just added the testimonials this morning so they definitely can be spruced up I think :)

Archiving is definitely in the works. It'll be opt-in, per list, that way we still never save any emails by default.

Thanks! I think those are both great suggestions - I'll see what I can do.

Suggestions like that are really helpful as I am definitely not a designer (IADNAD).

In the short term, I don't :P. I have some long term ideas, ideally keeping it ad-free forever.

when somebody tries to add you to the second one it'll be automatically renamed (just for you, not for everybody else) to family1@fiesta.cc - you can then go into the web UI and rename both however you want!

The ".cc" is meant to evoke the act of CC'ing somebody in an email, or creating a mailing list just by cc'ing somebody.

Also, they wanted like $1M for fiesta.com or something :P

oh awesome! he is a great guy

Yup, can add (or remove) addresses at any time using the "List members" link at the bottom of every fiesta email you get.

We've got some basic spam prevention already in place with some more advanced ideas being implemented soon.

You're right though, if all else fails the welcome email will just end up having an opt-in link.

Only members of the list can send an email to the list - since the list names are tied to the sender's address you don't need to worry about uniqueness (ie. my family@fiesta.cc is different than your family@fiesta.cc)

thanks!

Yeah the plustag thing is really the advanced UI - if you click "List Members" on the bottom of any emails you get from fiesta (including the welcome email), you'll see the web UI.