I don't think this has anything to do with moot (also an HN user).
He has some data from his websites (4chan, Canvas) and he has links to other people involved in web forum technology, so a discussion forum from him could involve some interesting ideas.
It's interesting just how differently anonymity works on sites like 4chan (many people have said that anonymity + Internet = assholes) compared to the original Japanese version of 2chan, where the founder has said
> [...] delivering news without taking any risk is very important to us. There is a lot of information disclosure or secret news gathered on Channel 2. Few people would post that kind of information by taking a risk. Moreover, people can only truly discuss something when they don't know each other.
> If there is a user ID attached to a user, a discussion tends to become a criticizing game. On the other hand, under the anonymous system, even though your opinion/information is criticized, you don't know with whom to be upset. Also with a user ID, those who participate in the site for a long time tend to have authority, and it becomes difficult for a user to disagree with them. Under a perfectly anonymous system, you can say, "it's boring," if it is actually boring. All information is treated equally; only an accurate argument will work.
I thought he was involved as well (considering the name) which made the manifesto claim about reducing "memes, funny pictures, viral videos" funny considering that moot builds products that are just the opposite of that.
> Any further letters from Mr Poole and his legal team would be met with a lawsuit for malicious prosecution, they warned in comments given to Betabeat.
For 3rd party widgets, I actually prefer iframe for security. The same domain policy makes it more difficult for xss in the iframe to compromise the parent page. For HTML5 sandbox iframes, the security boundaries are even more strict and tunable.
There are some disadvantages to current iframes that Moot addresses like the lack of CSS cascading from parent page to iframe. The seamless iframe spec addresses this issue, but it's not widely adopted yet.
Iframes are easily spoofable. I can generate an iframe, style it exactly like your authentication page, and trick users into entering their username/password into my phony form.
This is why mature platforms use dedicated windows for logging in (Facebook, Twitter, Disqus). I'd recommend you consider making this change.
An example attack iframes would make more difficult is XSS in the comment fields, e.g. an attacker bypasses sanitization and injects js into a page. With a sandbox iframe, the comments section could be restricted from compromising the top level page, e.g. stealing cookies, redirecting, etc.
Correct. If the 3rd party js properly sanitizes user input, this xss attack is moot. However, browsers love to eval stuff (http://html5sec.org/), and sandbox iframes provide good defense in depth. Secure programs like qmail have been using separate, sandboxed processes forever, but this secure design model has only recently been possible in the browser thanks to iframes and postMessage (http://www.cs.berkeley.edu/~devdatta/papers/LeastPrivileges....).
The client obviously strips out any SCRIPT/HTML tags from the input but I guess your're talking about something more clever here. Can you provide an example attack that could potentially pass our security?
Sanitization and protection from attacks is handled by the API itself instead of the client. We feel it's inherently risky to rely on the client at all for any security.
Thanks for responding. I would argue the opposite, that the browser is the safest place to sanitize because it better understands the context where user generated strings will be inserted.
An example where the server may not understand the correct context occurs in this utf7 attack (http://html5sec.org/#charset). The server sanitizes the user input as utf8 where it passes. The client forces the browser to interpret the input as utf7 instead, and the string that was harmless as utf8 now becomes active js.
This looks seriously interesting. It could be everything I've wanted Disqus to be - and their service has only really gotten worse over time.
Don't know about the forum aspect, but the comments design is great. I hope you can enforce whether it is linear or threaded from an admin point of view.
Yes, you pick whether your comments are linear or threaded and you can mix and match (use threaded in some places, and linear in other places). It's configured simply by how you embed it.
Wow, seems to cover a lot of use cases. I wonder how it compares to discourse.org
What confuses me a little is the part in the manifesto, where they basically claim, Moot will reduce trolling and memes and make conversation more meaningful. I think that any technical platform can be compromised, no matter how sophisticated. Sure, you can reduce trolling by voting etc., but how is technology supposed to help if the users themselves are not providing enough meaningful content?
The biggest difference Discourse is a Ruby application that is installed on your own server - and it cannot be integrated on your site, at least at the moment.
We can reduce trolling and memes with UI design and by not allowing pictures or rich text editing. You can see it already on our new forums:
Though you're probably right that rich text editing does enable less meaningful discussion, I'm still sad that it's not a thing. I've always quite liked being able to write using, say, markdown.
Discourse founder here. I tried their demo forum but it currently isn't responding. Probably too much load from HN although their home page claims they can handle 1k posts per second (trollface).
From a cursory point of view, it seems to have more in common with Disqus than Discourse. It's embeddable, doesn't allow rich posts or markdown or our support for embedding videos, github, wikipedia, amazon, etc.
It's also closed source, although it is free and they claim they'll never insert ads.
I have no idea about their support for the other challenges we've faced such as infinite scrolling that is compatible with the back button.
I am skeptical of redis as their only data store. We use redis too in Discourse but this would demand that all forum content can fit in memory at once, and there is a chance if a server crashes you'd lose so. Not to mention querying it is much more difficult especially when filtering.
Nice!! I can clearly see from your tone that we're now competitors :)
As you can see, we specifically don't allow images, rich text editing or videos. We want to focus on content and the discussion. Our minimal design emphasizes this.
We also think that infinite scrolling is bad UI design. We had it on our early versions but took it away. Much clearer without - you should try too! But of course, the more we differ the less we compete with each other.
Nothing personal, just as makers of forum software, anyone else who makes some is a competitor by definition, even if we are both free products.
I'm happy to have many others in the forum space as it legitimizes our cause and pushes everything forward. Our main goal is to modernize forum software and so is yours, so we're fighting the same battle here.
Also there's no way we're backing down on infinite scrolling :)
Totally agreed. We were excited when you guys launched for the same reasons. Further validates the space! There simply needs to be more options, and it's great that there are people getting interested and creating products in this area.
Our demo forum is in a sandbox environment separate from our primary network and it's getting traffic and loading (at least based on our logs). The production system is still pushing median API response times of 1.608ms (a drop of 0.2 since I last looked).
As far as redis, we've put a great deal of effort into our redis infrastructure. We heavily shard and replicate data in such a way that memory constraints are not our biggest concern.
By "You will have full access to your data at all times (*)" - do you mean for the user or for the site that embedds a forum or maybe both? Do you plan for data export for both user and site ?
Our infrastructure is designed from the ground up to handle the kind of spikes and massive loads that viral and social sites tend to generate. A million init- requests costs us very little. We can cover the expenses with paid products that are introduced later: these paid products allow private posts and custom branding for example.
The features you see on our site now will always be free.
crumbling? median api response times are 1.446ms at the moment and basically all our servers are completely idle. Any issues would be new bugs for us to track down!
