Introducing Tent - the decentralized social web - <AUTHOR> http://tent.io/blog/introducing-tent <comment><USER3> My first thought was "Well, Diaspora with another name". But after reading and understanding it (it's not very well explained there) seems like a much more abstract thing. They want to build an abstraction layer to the social web, not a social network.

The idea seems pretty good. It's just the basics: you follow people and receive their content (text, images, whatever), and people follow you and you share content with them. The most amazing thing is that, just using these simple concepts the possibilities are infinite. As they said, every social network out there can be implemented in this way. ¿Twitter? It's trivial, just make the format description and you're ready. ¿Facebook? The only thing you should specify is that the relationships are symmetric (you can follow me only if I decide to follow you too, that is, we are mutual friends).

To me, the idea seems absolutely great. The problem will be execution: what apps are created using this protocol. I have also the doubt if apps will be interoperable. Example: I build a twitter-like app named Foo and another guy builds another twitter-like app named Bar. Both use similar formats, so, can an user using Foo see the contents posted with Bar? I imagine that this will be possible as long as they share the same post format, but I'm not sure.

Anyways, good work. I would really like to see Tent to expand and grow.

<comment><AUTHOR> We are putting together a wiki-style solution for community-curated post types. Common types are expected to be standardized so that apps are interoperable. For example status/microblog would be a standardized post type. We will launch with common types specified, so that everyone doesn't reinvent the wheel. After that, community managers will help keep the devs in line.

<comment><USER4> One issue I can see is that you only need to have one friend who uses a third party tentd with questionable privacy policies and now everyone they're connected to has their data exposed. Would it be possible to implement it such that you can say 'yes, you can have this data, but only if your server is not being run by 'blacklist' (would have to assume the requesting sever doesn't lie about it's identity).

On the positive I can see this catching on because it's easy for existing social networks to integrate, it would almost become do or die forever more if a network that does integrate them catches on

<comment><USER5> Maybe this could be done by a IP/DNS blacklist on your API side. So you maintain a list on your "exit node" so that everyone who requests your data needs to be "a good guy". If this part would be done by the requester it could be spoofed easily, so it had to happen on the exit point.

</comment></comment></comment></comment><comment><USER6> A few years back, I started getting interested in a similar idea. I'm definitely intrigued in seeing how well it goes. Good luck to you.

Of course, as ideas go, I allowed myself to think further into the possibilities, and found some interesting avenues.

For instance, why allow the facebooks, twitters, etc to own domain over our content? Let people store their own data, and offer API endpoints giving facebook, twitter, etc access. They essentially become frontends and search engines to our shared content. We get control of our own data (and privacy therein), they get to provide an interface to that data in a way that fits what they're trying to offer their "customers".

And then if you take that even further, why allow anyone control over your data? Why not store all my purchase data and credit info on my own servers, and allow authorized companies access as needed? Census time? Popup shows up on my phone asking if i'd like to allow the government access to some of my data for census - I pick what data is allowed, and it's done.

Electric company's system automatically logs in to get my electric usage. Phone provider does the same. Publishing a book literally allows access by readers to your own servers. Releasing an album - same deal. We still have "stores", but those stores are merely search engines offering a service to both the content creators and consumers.

It went further, and weirder (in interesting ways). I'm not sure such a system would truly be beneficial, but I love the idea of allowing people to Truly Own their own data.

Apologies for the tangent. Good luck to you. I'm a fan of the idea as it's presented and I hope you're successful.

<comment><USER7> It's a great concept, but here's where it breaks down: once data is given out, it can never be retracted. Whether it's an author's novel or a shopper's purchase history, once the data is released to someone in a readable format, they are unable to stop the recipient from doing something they don't like with that data.

Granted, the issue can be mitigated with trust networks, social conventions, or laws, but it comes down the same issues faced by DRM media formats: if someone can consume the content, they can find a way to duplicate the content.

<comment><USER8> Just because you cannot prevent all threat models, does not mean you through privacy out the window. For example, if Alice wants to send Bob a message, in the current system: 1) Alice tells Facebook she wants to friend Bob 2) Facebook tells Bob, who accepts 3) Alice sends Facebook the message addressed to Bob (I think in plaintext) 4) Facebook sends the message to Bob. 5) The message is still unencrypted on Facebook servers, where it is available to Facebook, advertisers, hackers, and government agencies

Using known cryptographic methods, we can construct a system that works as follows:

1) Alice looks up Bob's public key (or gets it from Bob to avoid needing a trusted key service) 2) Using Bob's public key, Alice encrypts a message 3) Alice sends the encrypted message into the network, addressed to Bob 4) Using his private key, Bob decrypts the message

In the second example, the recipient (Bob) is the only one who can release the data. In the first example, a number of potentially malicious parties have access to the data without corporation from Alice or Bob.

I used a direct message for simplicity, but we do have crystallographic methods to encrypt a message such that an arbitrary group of people can decrypt it.

<comment><USER9> > we do have crystallographic methods to encrypt a message such that an > arbitrary group of people can decrypt it.

This doesn't solve the problem you're responding to: "once data is given out, it can never be retracted". That remains the case. If you encrypt your photo so that each of your 770 friends can decrypt it, but then you unfriend Bob for being a jerk, he's still got the key and the encrypted data. So he still sees that photo.

In contrast, although you could theoretically save every photo and update anyone ever lets you see on Facebook, it would be difficult enough that in practice no one does.

<comment><USER10> > "once data is given out, it can never be retracted". That remains the case. > If you encrypt your photo so that each of your 770 friends can decrypt it, > but then you unfriend Bob for being a jerk, he's still got the key and the > encrypted data. So he still sees that photo.

That particular photo, yes. But Bob could also have saved that photo as soon as he saw it or maybe he's got eidetic memory, so crypto can't help with that anymore.

However, any new photos shared through the same channel can't be seen by Bob anymore because I assume the key changes as the members of the access group change.

Still, while you can't solve the original problem (Bob _can_ leak everything), you can still do _slightly_ better than that by properly implementing Off-The- Record messaging[1]. This adds perfect forward secrecy, as well as deniability: The latter is very interesting because in OTR it means that _both_ parties can authenticate received messages to be certain of the sender's identity, but they can _also_ FORGE any message to look like it's been signed by the other. This means that even if Bob decides to publish your private messages to him, he can never _prove_ you were the one that wrote and signed them, because he could have forged them himself.

Two problems with that: I'm not sure how the OTR protocol extends to multiple recipients (but I bet there's some research on it), and while this "deniability" might be enough for private (text) messages, it's not much use for photographs in many cases: If Bob decides to publish an embarassing photo of you that he had once access to, it's not going to be much use that you can argue "ha, but you can't _prove_ I sent you that photo!".

Still, for textual communication, it adds a (thin) layer of extra security even though you can never beat Eidetic Bob.

[1] <http://www.cypherpunks.ca/otr/index.php#docs> and in particular <http://www.cypherpunks.ca/otr/otr-codecon.pdf>

<comment><USER9> I addressed the "Bob could have saved that photo" point: "although you could theoretically save every photo and update anyone ever lets you see on Facebook, it would be difficult enough that in practice no one does." Facebook has a sane default of _not_ saving everything that you view on your computer. Yes, maybe someone saved one or two photos, but they probably don't have them all.

OTR is pointless for a medium that's mostly about photo sharing. For the Facebook use case, what's far more important than crypto is the set of social norms the site establishes via what's easy to do (share) and what's hard, e.g., archiving everything your friends share as it comes in. Not only would that be tricky to do without getting detected as a bot, but 99.9% of users would never think to try it. This problem is inherently more tractable with a distributed system, and that could be bad.

</comment></comment></comment></comment></comment></comment><comment><USER11> Random thought: it might be helpful to give Tent-the-protocol a different name than Tent-the-server-implementation. In other words, "Tent" means either the protocol you're specifying, or the server software you're planning on releasing, but not both.

An analogue would be the naming distinction between HTTP, the protocol, and httpd, the first Web server (<http://en.wikipedia.org/wiki/CERN_httpd>). That naming split made it easier for people to understand what part of the system others were talking about, and helped make it clear that the two pieces were not tightly coupled to each other.

Maybe you're already planning on doing this when you release the server, it's not clear from the web site. If that's the case, feel free to ignore...

<comment><USER12> Definitely-- The first "Tent server implementation" will have it's own name, TBD. We spent a lot of time on nomenclature and still aren't 100% with any of the terms, they're effectively all in flux until v1.0. The wackier issue is whether users call their "Tent-servers" "Tents". If you have any suggestions on names for this or any other terms, we'd love to hear them!

edit: when the hosted version launches it will be on a different domain, to make clear tent.io is the protocol alone and we aren't monopolizing the hosting space (we're doing it more as a community service than as a business).

<comment><USER13> A collection of Tents could be called a "Camp".

<comment><USER14> A cluster of camps, perhaps related to a specific topic, could be called a 'Jamboree'.

<comment><USER13> Jamboree sounds a little too campy.

</comment></comment></comment></comment></comment><comment><USER15> Why is it that every new protocol seems to want to piggy back on HTTP? It seems to me that maintaining state would be a useful feature for a social protocol.

Another issue is that this assumes that the web will be the client of choice in the future... with mobile apps being as big as they are in the social space, this seems a bit shortsighted.

Don't get me wrong, I like the idea behind having a "social server", but I don't necessarily think that starting with HTTP is the way to go.

I don't have any particular argument with using JSON for data transfer though... I think that is probably a good choice. Also using SSL for all connections is probably a good call too.

<comment><AUTHOR> HTTP accomplishes all of our design constraints via REST and long-lived streaming connections. It is a very reliable, mature protocol, and the security and performance are very well understood. Also, if we invented a new binary protocol, users wouldn't be able to host their Tent servers on easy-to- use platforms like Heroku.

Developers may implement other protocols in the future, but we are targeting HTTP as an accessible starting point.

We are definitely anticipating heavy mobile use, both through mobile web apps as well as native. There will eventually be iOS and Android frameworks to handle all of the communication with Tent servers.

<comment><USER16> HTTP is a huge, hefty, inefficient and complex protocol whose only advantage is that HTML/JS supports it by default. Arguments that 'websockets' solve this are ridiculous in the face of the fact that we can just use 'sockets', like we always have. WebSockets are a work-around for the constraints of the browser.

As a mobile/desktop/server engineer, I would _love_ the opportunity to work with other server-side teams that aren't wedded to the web/HTTP via historical accident and thus don't force us to use HTTP.

<comment><USER17> HTTP implements an architectural style which ensures reliability, scalability, decoupling of systems and support for hypermedia for a complex network of disparate, unreliable systems and networks.

Do you have any suggestion that provides the same features, or should we forgo them because HTTP is "hefty"?

<comment><USER16> > _Do you have any suggestion that provides the same features_

Message passing.

That's all HTTP really is, but it's dressed up in a bunch of historical complexity and inefficiency centered around supporting web browsers.

<comment><USER17> But do you have any concrete suggestions of protocols, or are you criticizing the choice based on an hypothetical protocol that would be very similar but incompatible with HTTP and all its existing tools (millions of tested and deployed caching servers, load balancers, etc), and for which whole new libraries would have to be written, just so you can make it somewhat more efficient?

<comment><USER16> I think you're grossly over-estimating the difficulty of defining a protocol. It's no more difficult than defining the protocol for which you'll use HTTP as transport.

Load balancers know how to load balance straight TCP. HTTP caching servers are an HTTP-centric idea.

The 'libraries' you'll need can be much, much smaller when all you need is a bit of framing and serialization, instead of a complete complex RFC compliant HTTP client stack.

<comment><USER17> _I think you're grossly over-estimating the difficulty of defining a protocol._

It's not writing the protocol that I find the most difficult. It's reimplementing everything the uses the protocol.

 _Load balancers know how to load balance straight TCP._

Which is only useful if all the nodes are exactly the same, but that prevents you from distributing the data across them based on the user profiles, and then load balance according to the user id, as (if I'm not mistaken) Netflix does. Since they're using subdomains as user identifiers, you'd get that for free using an existing, well-tested HTTP load balancer.

 _HTTP caching servers are an HTTP-centric idea._

That's a tautology. The question is: are they a _useful_ idea? Is being able to take advantage of existing and deployed solutions like CDNs useful? Seems to me like it would be.

 _The 'libraries' you'll need can be much, much smaller when all you need is a bit of framing and serialization, instead of a complete complex RFC compliant HTTP client stack._

I think you underestimate the advantages that some of the core HTTP concepts provide.

<comment><USER16> > _Which is only useful if all the nodes are exactly the same, but that > prevents you from distributing the data across them based on the user > profiles, and then load balance according to the user id, as (if I'm not > mistaken) Netflix does. Since they're using subdomains as user identifiers, > you'd get that for free using an existing, well-tested HTTP load balancer._

I'm not sure what you think makes that complicated to implement without HTTP, or why you consider it 'free'. Netflix had to write custom code to support that, and could have just as easily done so on top of a message passing architecture ala ZeroMQ or even AMQP.

> _That's a tautology. The question is: are they a useful idea? Is being able > to take advantage of existing and deployed solutions like CDNs useful? Seems > to me like it would be._

Not really, no -- neither a tautology nor are they particularly useful for API implementation. Their primary value is in caching resources for HTTP requests in a way that meshes well with the complexity of HTTP.

If you need geographically distributed _resource_ distribution than HTTP may be a good idea simply because:

\- There's widespread standardized support for HTTP resource distribution.

\- Its inefficiencies are easily outweighed by the simple transit costs of a large file transfer.

We're largely talking about server "API", however.

> _I think you underestimate the advantages that some of the core HTTP > concepts provide._

No, the core concepts are more-or-less fine. It's the stack that's inefficient and grossly complex, largely due to browser constraints and historical limitations.

<comment><USER17> _I'm not sure what you think makes that complicated to implement without HTTP, or why you consider it 'free'. Netflix had to write custom code to support that, and could have just as easily done so on top of a message passing architecture ala ZeroMQ or even AMQP._

It's free because it already exists. Load balancers for hypothetical protocols don't.

 _Not really, no -- neither a tautology nor are they particularly useful for API implementation. Their primary value is in caching resources for HTTP requests in a way that meshes well with the complexity of HTTP.

If you need geographically distributed resource distribution than HTTP may be a good idea simply because:

\- There's widespread standardized support for HTTP resource distribution.

\- Its inefficiencies are easily outweighed by the simple transit costs of a large file transfer.

We're largely talking about server "API", however._

Isn't the whole point of this system to transfer people's content - posts, pictures, videos, etc - between servers? I would think pure API "calls" would be a small part of the whole traffic.

 _No, the core concepts are more-or-less fine. It's the stack that's inefficient and grossly complex, largely due to browser constraints and historical limitations._

But to implement them, you need more than "a bit of framing and serialization".

<comment><USER16> > _But to implement them, you need more than "a bit of framing and > serialization"._

I posit you're still __grossly __overestimating complexity based on your own experience with HTTP, coupled with grossly _underestimating_ the complexity, time costs, and efficiency costs of the stack HTTP weds you to.

A TCP stream is simple. It's as simple as it gets. Load balancing it requires a few hundred lines of code, at a maximum. It only gets complicated when you start layering on a protocol stack that is targeted at web browsers, grew over the past 20 years, requires all sorts of hoop-jumping for efficiency (keep- alive, websockets, long-polling), requires a slew of text parsing and escaping (percent-escapes, URL encoding, base64 HTTP basic auth, OAuth, ...), cookies, MIME parsing/encoding, so on and so forth.

All this complexity is targeted at web browsers, introduces significant inefficiencies, and requires huge libraries to make it accessible to application/server engineers.

What's the gain? Nothing other than familiarity, as evidenced by your belief that the _core_ of what HTTP provides is so incredibly complicated, and you couldn't possibly replace it.

No -- it's the complexity of HTTP that's complicated, not the concepts that underly it. Drop the HTTP legacy and things get a heckuvalot simpler.

<comment><USER17> It's not so much that you can't replace HTTP, as that you can't replace all the thousands of tools and packages that already work with HTTP, and that can be very useful for a project like this. And you can't easily replace the knowledge that people have to HTTP either. (Claiming that OAuth is part of HTTP doesn't help with your credibility either, I'm afraid.)

Furthermore, I think that even if the developers of this project could replace the required tools and forgo the rest, I doubt it'd make sense.

Frankly, you'd need a working prototype to convince me of the contrary, so I guess we'll have to leave it at that. I'm a stubborn man ;)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> This would be the "killer protocol" for the freedombox, if combined with some smart dyndns management.

Here is a use case scenario I am imagining. I define two servers for myself: home.me.com and cloud.me.com. Where home.me.com is a dyndns to the freedombox. Dyndyns being unreliable, if a tent msg cannot get to my home server, then the messages are sent to cloud.me.com and then pushed to home.me.com when it comes back online (think POP mail).

The facebook killer then, is a hosted service like cloud.me.com for non-tech people, but a seamless transition to the hosted at home service as soon as you buy a freedombox. This way you have the best of both worlds. Your face in the cloud, and long term storage at home.

Other app wishlist: tent to smtp and smtp to tent adapters for gmail killing

<comment><USER12> hosted service within one month. email apps VERY high on our to do list, been watching freedombox for a while, we'll reach out to them after initial release.

<comment><USER19> Since you mention Freedombox – did you also check out ownCloud as well as the unhosted movement, with the remoteStorage protocol? There is a proof-of- concept social network build on unhosted: <http://friendsunhosted.com>

Do you have an IRC channel? Feel free to also join our channel at #unhosted. :)

</comment></comment></comment><comment><USER20> I am not convinced that this needs a new protocol as they claim. Facebook- style functionality be done on top of activity streams, pubsubhub, salmon, webfinger et al. They indicate they have investigated existing systems and found them lacking. I would rather have something like this built on protocols that a bunch of people have discussed out in the open first. That said, I am interested to see more details as they arise, as this type of thing is needed.

<comment><USER11> Or at least some hard details about _what_ those existing alternatives are lacking. That could lead to further improvement, as whatever communities have already formed around those alternatives could debate the questions and possibly improve their protocols.

As it is the FAQ reads like "those are old and busted, we wanted something new and hot," which gives off an aura of NIH syndrome.

<comment><USER12> We take NIH very seriously and originally began by attempting to revise existing protocols. We have some very specific complaints about existing federated web protocols:

• no support for private message (pubsubhubbub, anything atom-based) • inability to move relationships when changing service • no standard API for application interaction

by leaving each of these (and others) out of scope see: [http://ostatus.org/sites/default/files/ostatus-1.0-draft-2-s...](http://ostatus.org/sites/default/files/ostatus-1.0-draft-2-specification.html#anchor4) they have created an ecosystem unfriendly to developers (who have to approach each provider separately to work out auth schemes and APIs) and likely to lead to vendor lock-in (because relationships can't be transferred and basic features are implemented differently in each system).

<comment><USER11> This is valuable -- I'd recommend adding a page to your site that includes these types of critiques, it'd be useful for those working on or around those other protocols. And it'd give people who are interested in your work a URL they could send around when asked "why not just use salmon/webfinger/ostatus/whatever."

<comment><USER12> Thanks, that's a good note. We didn't want it to seem like we were attacking the other protocols (all of which have had success, have clear use cases, and we owe some debt to for paving the way), but we should make our reasoning clearer to the community. Will do.

</comment></comment></comment></comment></comment><comment><USER21> This looks great guys. I'll definitely put up a server and hook up the content I traditionally expose through my personal website.

Question: what features that are taken for granted on today's popular social networks are difficult/impossible in this kind of distributed system? for example, i suspect something like "friend suggestions" might be difficult, since you only have access to a part of the network. Auto-friend tagging in pictures would be tough too. I'm seeing a lot of upsides listed, but there must be some things you just can't do. A candid discussion of the drawbacks would be helpful.

<comment><USER12> There are a few "standard features" of centralized social networks that are more challenging to implement, but we haven't found anything impossible yet. Search, especially real-time requires an external search engine. But it means Google (et al) needs to subscribe and essentially ask your permission for real time updates. Friend search is a bit easier if your followers/people you're following are public. Likely there'll be an app for that.

<comment><USER22> A couple of things I don't see on a quick scan of the docs:

(1) I don't see how one Tent entity contacts another proactively - it looks like A can't message B unless B has already chosen to follow A. If this is so, is it an anti-spam measure? Given that StatusNet etc. are infested with spam, it seems like a very wise one :-) On the other hand, it is rather limiting as compared to centralized platforms, don't you think?

(2) I don't see how you maintain the promise of a portable identity when your identities are hosted URIs. Eg, if my identity is tent.is/foobar, and I want to move to a different host, how do I do that? I can download my data, sure. It looks like I can even bounce from tent.is to another data server. But unless I want to break all my social connections, don't I remain at the mercy of tent.is? This strikes me as a rather unsolvable problem, but it would be reassuring to clarify that you're not solving it :-)

<comment><AUTHOR> 1) This isn't clear in the docs right now, but unauthenticated notifications are allowed, and eventually we'll add signing (think Domain Keys).

2) Every piece of data in the system will be available via the API including negotiated app and follow credentials, moving will consist of authorizing an importer app to have read access to everything, and then pushing a post that tells all the servers to check the profile again for updated entity and server details. It should be a very simple process.

<comment><USER22> (1) Have you thought about spam, then?

After all, there's a reason social services are centralized on today's Internets. The reason (IMHO) is that the Internets since 1992 or so have been an antisocial network, and anything worth attacking that lacks a centralized defense command is rapidly overrun by digital Huns. For instance, SMTP exists today because it existed before eternal September, and being valuable was (barely) defended; but if it didn't exist as a legacy from the old, social Internet, it would be very difficult to create it in the new antisocial one. If not impossible.

I mean, it's certainly not that some of us rotting old neckbeards weren't using finger and talk on the firewall-free Internet in 1989. So we know how cool it would be if some bright young whippersnapper could solve teh problem...

(2) This is useful but inevitably imperfect, as forcing every interlocutor to equate the old and new names is of course impossible. Eg, HTTP redirects make it possible to change your DNS identity - but hardly trivial, though the redirect itself is trivial.

And of course it's a process that your existing host could easily frustrate, though that would be very ill-mannered. Not saying there are any perfect solutions here.

<comment><USER23> (not associated in any way with tent.io)

1\. Just because it is allowed by the protocol doesn't mean any given client needs to pay any attention. Just like email, I can filter out any messages from people not in my contacts. I may choose not to and instead run each one of those messages through a spam filter. In this respect it really seems no different than email. Individual clients/servers can choose to be as strict as they like (but servers are servers, and they are sitting on the internet, so spammers can see them and send messages that will be ignored if they like).

2\. Since connections with most of your contacts are theoretically maintained so you can push out new data, updating is more akin to propagating a new ip through the DNS system than using a redirect. Yes a DNS server can misbehave, but that can only screw up a network of well behaved servers for so long.

<comment><USER22> 1\. People learned (grudgingly) to use spam filters with their email because they had an existing service which had achieved large-scale network effect in a spam-free environment. A new service which develops a spam problem before it achieves critical mass is much more likely to be abandoned.

There must be some reason we haven't seen successful new decentralized service protocols on the Internet since the early '90s. I don't know of a more obvious one.

You can see the issues with StatusNet and spam:

<https://www.google.com/search?q=statusnet+spam>

2\. The problem is that contact names propagate outward from the master state where a push will update them. For instance, they get written down on business cards. They also get cached, imprudently but inevitably, in forms that are still digital but don't update properly.

Imagine a protocol that you could use to update your email address this way, and you'll see the problem. In theory, you could design a special SMTP message that would cause all clients to update their address books. In reality this would scale quite poorly and be quite unreliable, leading people to avoid it, leading it to be even more unreliable, etc. Of course, your chances are much better with a bright, shiny new protocol... but still.

<comment><USER24> RE 2. I agree since some servers that you are trying to push your new address may already have changed theirs. What happens then? Do my friends inform me? What if that unreachable server is not connected to my friends in any way?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> I wonder about the rationale to use HTTPS for everything, especially about the SSL part. It seems that by the choice of SSL over a web of thrust (WOT [1]) approach one imports the problems of certificates and CAs into the protocol. Especially it would be possible for a server with a root CA to impersonate other people. On the other hand, a social network is about social relations, which could also directly serve to sign and validate public keys in a WOT. This could then serve as a authentication against the same social network that is stored. For example a chat software could show Alice that the person she is chatting with is indeed Charly, the friend of Bob ( Bob signed Charlies key).

[1] <https://en.wikipedia.org/wiki/Web_of_trust>

</comment><comment><USER26> I'm damn excited about this. I've been mulling this concept over in the last couple of years, because I really we need something post-blogs that isn't the walled garden facebook / twitter / G+ / et al model.

For the me the ultimate social network would be just blogs, RSS and a feed reader, with people either managing the blog themselves or using a third party to do it for them-- the point is it doesn't matter.

The problem is that blogging is complicated, anything with multiple options is complicated, and discovery is complicated. I know where to look to find a friend on facebook, I don't know where to look to find his blog.

I don't have time right now (work) to look into Tent in more detail, but it sounds like it's a definite step in the right direction.

</comment><comment><USER27> It seems like this will use up a crapton of bandwidth with its 'push' style notifications. If someone with a million Facebook followers makes a new post, one entry is made in the database and then users pull it down as they visit their own pages.

If a million people decide to 'camp in my tent' (?), my server is suddenly pushing out gigs of data every time I make a post.

<comment><USER12> We anticipate follower counts similar to the levels seen on Twitter today. Managing 1 few hundred followers isn't too difficult, thousands can be managed by cranking up the dynos on heroku. But yeah, Justin Bieber is going to need a hosted solution to handle that kind of load (like he has now with Twitter, YouTube, etc).

We also have a setting in subscriber settings that control which types of posts are pushed in their entirety to different followers vs just a notification being sent vs nothing at all. So blog entries and status updates might get pushed to all 1M, but you probably wouldn't push an HD video update to all of them without some more serious server architecture.

<comment><USER27> What arguments do you have against a 'pull' style for notifications? Something like a GET to /latest that passes in the last time the client checked for updates and only gets back the URI of the last 10 or so posts since then. An HD video post could contain simply a URI that points to the video, so the video isn't even downloaded until the 'app' within tent asks for it.

This way you could have a path with all the videos on it that you could proxy off to a server with more bandwidth. It would get the user a lot more control over how their content is accessed.

Edit: And what if my server is down when one of my friends makes a post? Will I never see it?

<comment><AUTHOR> Pull-style requests actually use up quite a bit more bandwidth than push notifications, because every client and server has to query every few seconds instead of just getting notified when there is a new post.

Posts have 'views', so a video or photo post would be pushed out with the 'meta' view which would include a URL to the content instead of the content inline.

<comment><USER27> I don't think so, considering that not all of my followers are going to be using the service all of the time. If the server just blindly downloaded everything always, then yes, it would be more bandwidth. But with proper caching strategies and servers only requesting new posts when clients are active, I think you could save a lot of bandwidth by not pushing everything.

</comment></comment></comment></comment></comment><comment><USER28> This is the Twitter replacement gotham needs.

Repo starred, eagerly awaiting runnable stuff.

</comment><comment><USER29> I would be interested to read a 'big-picture' description of what Tent is. Forgetting for the moment how it compares with competitors, what is the idea? I read the introduction but I feel that I don't understand it.

From what I can tell, the idea is to create a standard set of objects and rules for interacting with these objects. Of course that is how protocols tend to look.

What are some of the new objects/concepts proposed by Tent? For example, is there a distinction between "home" and "users" akin to server/client? Are there several types of messages, compared to email? Is there a standard cookie-like object? What is the conceptual model for sharing? Any insight would be appreciated.

</comment><comment><USER30> Awesome. I've wanted this forever, glad someone is finally picking up the ball and running with it. I'll be happy to beta test!

<comment><USER12> How do you feel about alpha? please join the mailing list (on the bottom of <http://tent.io>) so we can let you know

</comment></comment><comment><USER31> "His server sends a notification to every server following him or mentioned in the post with permission to see the post."

The protocol seems to have some fundamental limitations.

For my money I'd rather go with FETHR (see <http://dsandler.org/brdfdr/> and this paper: <http://dsandler.org/brdfdr/doc/iptps-fethr/>) and its implementation - which has code available right now (<https://bitbucket.org/dsandler/brdfdr/>).

<comment><USER32> Too bad that project never caught on, it seems really interesting and useful.

</comment></comment><comment><USER33> "Tent servers can also be run as Tor hidden services to create a social darknet for at-risk organizers and activists."

<comment><USER34> So can anything, but it's awesome that they are promoting this. Speaking of which, does anyone know if there's a hidden service Twitter clone? This would be fun.

<comment><USER35> TorStatusNet: <http://lotjbov3gzzf23hc.onion.to/>

<comment><USER34> Rad... thank you!

</comment></comment></comment></comment><comment><USER36> Thanks guys. Not a moment too soon. Humbly quoting the motivation:

> What is wrong with other social services? Centralized Social Service > Providers limit what you can share and who you can share with. They only > allow users to interact with other users on the same network. Because their > products are centralized and maintained by a company, users are left in the > cold when the company changes its products or shuts down. There's nothing > wrong with a company offering users social services. But users shouldn't be > limited by those companies. Imagine if you could only email other customers > of your Internet Service Provider. Unfortunately Centralized Social Service > Providers have done just that. You can only communicate directly with other > users of their closed network.

> If you don't like a bank you can withdraw your money and deposit it > somewhere else, including your own home. You could even start a new bank > where you and your friends felt safe. You can still pay your bills and > maintain your financial relationships, just tell them about your new > account. We aren't talking about money. Your data is far more valuable– your > family and friends' photos, locations, and private communications. You > should be able to store them somewhere you trust, move them when you want, > control who can and can't see them.

</comment><comment><USER37> We're building something like this for a while at Qbix.

It's not an easy problem to solve when it comes to privacy and security: <http://www.faqs.org/patents/app/20120110469#b>

Eventually to arrive at this: <http://myownstream.com>

<comment><USER38> Looks ambitious in liberating the user and their data, but it seems you've taken too long and have stumbled upon substantive problems on your own. The screenshot of the platform seems old fashioned, but eventually by liberating the user/data, you are making them stand on their own island, hence there will be no "networking" or connections in the true sense, as it is currently happening on a single platform like Facebook or Twitter. By attempting to set the data and user free in such manner and by eliminating the single and cohesive platform, we risk excluding ourselves out.

<comment><USER37> What do you mean

</comment></comment></comment><comment><USER39> What took you so long? I've been waiting for someone to finally get around to building this for a long time.

<comment><USER40> Appleseed, OneSocialWeb, StatusNet/OStatus, Disapora...

</comment></comment><comment><USER41> "How is Tent licensed? Tent will be completely free and open and treated as a standard. To prevent fragmentation before launch, the original authors currently retain copyright. This is a temporary situation which will be remedied immediately after a governance model is chosen. We decided it would be best to share what we could as soon as possible, releasing early and often. We are entirely committed to free and open software and protocols with open governance models leading to a ratified standard. Tent will be released under an open license in the immediate future."

I am curious as to how retaining copyright will help them prevent fragmentation? Can they not elect themselves as project leaders of the opensource project and prevent fragmentation?

<comment><USER42> Retaining copyright means that you can't fork their code to easily establish a working but slightly incompatible version, which is what fragmentation is.

Project leader is not a formalized position (or even a meaningful concept, really) in free software and doesn't come with the power to prevent forks or fragmentation. I guess their thinking is once a community of users and developers is brought together, they can be trusted to establish a model that retains compatibility since it is in everybody's interest. While at the moment, an incompatible fork would have the same "network effect" as the original.

Either way, the copyright only covers the software, not the protocol.

<comment><USER43> Retaining copyright isn't what matters. The license they choose on the copyright they (naturally) retain does.

It is possible that they could craft a license such that protocol-incompatible changes are not allowed, but I don't think that would be in their best interest. This is a starting point. The risk isn't fragmentation, it's crickets (ie nobody cares) and an untested protocol that may need multiple versions to get right.

</comment></comment></comment><comment><USER44> PHP support is vital.

<comment><USER45> really

</comment></comment><comment><USER46> I like how they support Tor hidden services. Though I wish they would go a step further and support I2P.

It's really nice to see people are working on ways to sort of "replace" the current centralized services out there.

Let us hope they are attractive enough to developers and users.

</comment><comment> mike-cardwell Sounds almost too good to be true. Looking forward to being able to download some software.

<comment><USER47> They've got a github repo they're working out of it looks like:

<https://github.com/tent/tent.io>

<comment><USER48> Argghhh. Ruby.

<comment><USER12> Only the site generator is in Ruby. While most of our core team are Rubyists, someone is working on a C++ implementation, too. It's a protocol which means you can write an implementation in any language you want. We hope to see many server implementations with different optimal use cases in different languages.

For libraries, Ruby and Javascript are our top priorities with Java and Obj-C/iOS to follow. We'd love help if there are other languages you'd like to write libs for.

<comment><USER44> Okay but there are more PHP users out there. If you had one PHP server I would start to run it right now. My (and many others) shared hostings do not provide Ruby, Java, C++ support.

</comment></comment></comment></comment></comment><comment><USER49> But how does this differ to StatusNet/OStatus? If we have several similar solutions to a problem it makes it more difficult for one to gain traction. Seems like reinventing the wheel, or am I missing something?

</comment><comment><USER50> I hope this crew is looking at WebRTC. The true killer app for a distributed social network is going to be a global decentalized video chat network. Imagine Google hangouts without Google. Even just to implement a voice-only chat without a centralized system would be pretty phenomenal.

Also, I really think they're making a mistake by not using secure Websockets for their protocol. Plain HTTP has too much overhead for what needs to be an efficient messaging protocol and the potential need for persistent connections.

</comment><comment><USER51> How does this compare with Diaspora?

<comment><USER12> Diaspora* is a federated open source social network. It does not have a protocol specification or an API for app support/integration. Diaspora* is not intended to be run as one server/user, but by clustering users on pods with pod administrators, etc.

<comment><USER51> Reading the API docs, it seems that every user needs their own URI to be uniquely identified. I wonder how this will work with the average user, just IP address? What about users with shared internet?

<comment><USER12> You're correct-- we anticipate users either registering their own domains (i.e. <http://danielsiders.com>) or using a hosted service that provides subdomains (<http://danielsiders.tent.io>). If you're hosting at home (dream solution here is plug computers), then dynamic DNS pointing to your home IP/computer.

<comment><USER52> PageKite (pagekite.net) is another solution for self-hosted from a household. _plug_

</comment></comment></comment></comment></comment><comment><USER53> I'm thinking about every smart phone as a tent server.

P2P camping site will establish when you are waiting the bus, taking the boring meeting, or camping at the river bank. I tried to use wifi- direct/bluetooth, but I found iPhone and Android system set device default to non-discoverable for security issue. But I do found a lot of Nokia/LG phone in discoverable mode on subway.

I hope the tent will be successful. Be an application to make strangers knowing each other and people to go outdoor.

</comment><comment><USER54> How does this compare to Mr Social? : <http://mobisocial.stanford.edu/papers/mrprivacy.pdf>

</comment><comment><USER55> I believe this is a great idea, but I disagree with some points of your implementation. I actually started writing a lengthy comment about this, and after about two hours of writing I decided it might look better as a blog post, so there you go:

[http://www.nicollet.net/2012/08/tent-the-right-goals-the- wro...](http://www.nicollet.net/2012/08/tent-the-right-goals-the-wrong- perspective/)

<comment><USER29> I find your post interesting, and it goes some way to answering my own questions. However, your post is based on the premise

"There are four issues with decentralized, large-scale sharing of content between non-technical people..."

and you claim those four issues are 1\. Identity Persistence 2\. Data Persistence 3\. Publishing 4\. Access Restrictions

I do not see why this is so. But even if it is, it is not even clear if the main point, at this stage, is to identify the atomic components of the "social web" -- perhaps what is sought after now is a slightly higher-level conceptual framework which puts these together.

For example, "publishing" may be missing the point - perhaps we need a finer grained concept: different kinds of collaboration, delegation of authority, distribution of tasks, self-communication, electronic cloud prayer...

</comment></comment><comment><USER56> This looks really neat. How are you going to get people to start using it? Anything more active than hoping that an app/user ecosystem develops?

<comment><AUTHOR> We are starting with an easy-to-use hosted service that will launch in a few weeks. We are catering to the development community by offering a simple, standardized API that will be easy to use. Privacy is a first-class feature, and Tent is specifically designed to be usable by high-risk activists[1] and people in countries that block other social networks.

[1] [http://liberationtech.tumblr.com/post/13377461578/how-the- ne...](http://liberationtech.tumblr.com/post/13377461578/how-the-next- generation-diaspora-should-be-built-to)

<comment><USER57> I don't mean this in a cruel way (I'd really like this to succeed), but that's a list of features, not a plan for getting adoption.

Figuring out how to bootstrap network effects is critical.

<comment><USER12> You're right-- Our plan is to get the protocol and reference server functioning for general use. We're mindful of the notes made here: [http://liberationtech.tumblr.com/post/13377461578/how-the- ne...](http://liberationtech.tumblr.com/post/13377461578/how-the-next- generation-diaspora-should-be-built-to). We have some thoughts on adoption tactics and strategy, but the master plan is still under development. All insights are welcome.

edit: wow, wrong link.

<comment><USER56> Twitter and LinkedIn are successful in distinct niches from Facebook. Companies and privacy-conscious people apart from activists (Germans?) may also be interested in a social network that lets them own their information.

</comment></comment></comment></comment></comment><comment><USER58> In my opinion, there isn't much point in decentralizing servers -- it's been tried and failed a number of times. What we need is decentralized _clients_ , e.g. a true P2P social network. Essentially, imagine that your contacts app could exchange messages over the Internet directly with any -- or all, or any combination -- of the contacts stored within.

</comment><comment><USER59> Where's the donate button when I really need it?

</comment><comment><USER60> "Not Invented Here" syndrome is manifested as an unwillingness to adopt an idea or product because it originates from another culture - <USER2>

The culture of decentralized web doesn't bode well, not enough capitalism, which might in turn effect the quality of the product.

</comment><comment><USER61> If anyone is looking to get involved I have (unoffically) started a project to write a testsuite against the protocol. Contributions would be appreciated.

<https://github.com/lucaspiller/tent-testsuite>

</comment><comment><USER62> > Tent is specifically designed to be usable by high-risk activists and people > in countries that block other social networks.

I can't help but read that and think, "terrorists." Then again, there will always be that tradeoff and you are probably on the right side.

<comment><USER39> Osama denied my friend request! :-( (Sad terrorist)

</comment></comment><comment><USER63> > OStatus [..] stopped short of actual decentralization.

How so ? It looks quite decentralized to me.

</comment><comment><USER64> Why not use the OpenPGP standard? PGP public and private keys seem to be the natural solution for both,

1\. signing data so that the source can be verrified

2\. encrypting messages so that they can only be read by particular recipients

</comment><comment><USER65> To a normal person, this article is just a collection of fuzzy well meaning ideas wrapped around a bunch of technical network jaron. The fact that there is no working demo is rather damming.

</comment><comment><USER66> Instead of sub domain, email address would have been a better choice.

email@example.com

Where provider.tld provides specification/api.. like robot.txt/tent.json that would specify actual api endpoints for given user.

<comment><USER17> I think both are unfortunate, since it ties your identity to your current provider. I'd much rather see a truly decoupled system, even if it didn't provide a "friendly" user id, but only an hidden fingerprint. People can just search for name and other data anyway.

</comment></comment><comment><USER67> Friendica does that already. No one cares. Potato chips are potato chips. No one cares about the brand, but everyone loves them, even though they are not free.

</comment><comment><USER68> Who's behind Tent, does anyone know?

I can swear I saw a section with names on the site, but can't seem to find it now. It looks like it was taken out.

</comment><comment><USER69> How is the different from identi.ca? Isn't this pretty much what their premise is/was? (ignoring implementation differences)

</comment><comment><USER44> <http://en.wikipedia.org/wiki/Tent_(protocol)>

</comment><comment><USER70> Who is building this? Who designed the protocol, and will publish/veto the standard?

</comment><comment><USER71> What happens when my server is down when you try to post a notification?

<comment><USER57> From the docs:

"If the app does not respond with 2XX, then the server should try again later."

"Shirley has her client in maintenence mode; jerrold.me will attempt to deliver the notification later using an exponential backoff algorithm."

</comment></comment><comment><USER72> I'm digging this!

</comment><comment><USER73> Please make more social networks.

<comment><USER74> Every day I wake up and I think 'If only we had more social networks!'

</comment></comment><comment><USER75> Website is down?

</comment><comment><USER38> "Every user decide which other users can follow them and what information will be shared with each of their followers."

This effectively makes each person an island in h/herself and hence the model of social-web breaks down. It wouldn't work and people know it.

In order to liberate the data, you're throwing the baby out with the bath water.

<comment><USER21> I'm not following your rationale. Isn't that Facebook's default model? I explicitly choose who is allowed to see my content, and I have control over how much of that content they can see through privacy settings / lists. The problem with Facebook is that I simply don't trust them with my data.

<comment><USER38> Yes, that's correct, hence Facebook's user feed is not really based on, or helping, the social-web part of the user's life. The user feed or stream is there as an advertisement, a selling product, for the product and services to advertise to (it is sort of a loop, isn't it - you are selling yourself to the one who is also selling to you).

The real social-web aspect of the Facebook is in their Groups, or Pages, where users collaborate, converge "together" on a single entity (of any particular Group or Page).

Do you follow my logic now?

I am against the idea of making users standing independent on their own because they then become an island in themselves. It is fine if you are making them a product, a brand, or portfolio, but none of this is helpful for the authentic social-interaction. You don't need a brand or portfolio to be social, that's not its original purpose. The original purpose of the user (individual human being) is to communicate, be social, create communities.</comment></comment></comment>


The real way to generate a list of primes in Haskell - <AUTHOR> http://www.garrisonjensen.com/2015/05/13/haskell-programs-are-lies.html <comment><USER2> Funnily, there's haskell-cafe thread[0], a github issue, and _even a paper_ , about this (and I think maybe reddit got involved too).

Anyhow, the title is kind of too much. At least, given the aforementioned discussions, we're conflicted liars.

[0][https://mail.haskell.org/pipermail/haskell- cafe/2015-April/1...](https://mail.haskell.org/pipermail/haskell- cafe/2015-April/119428.html) [2][http://www.cs.hmc.edu/~oneill/papers/Sieve- JFP.pdf](http://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf) [3] [https://github.com/haskell-infra/hl/pull/8](https://github.com/haskell- infra/hl/pull/8)

<comment><USER3> I don't get it. I simply see the example as an elegant way of introducing the power of the language. This kind of pedantry only drives curious people away.

<comment><USER4> Most people know it's not a real sieve of Eratosthenes and just a demonstration of Haskell concepts but there will always be people excited to educate others regardless of the context.

</comment></comment></comment><comment><USER5> As much as I hate the title of this post, I think the author has a point.

I've also seen this same thing come up when comparing implementations of quicksort in Haskell to that of other languages. They always show a short, elegant implementation in Haskell, but the issue is that it's not really quicksort as it doesn't do the sort in place.

<comment><USER6> > it doesn't do the sort in place.

That's one of the easiest ways to raise hackles among Haskellers -- they believe that parallelizability, not in-place sort, is the defining characteristic of quicksort.

</comment></comment><comment><USER7> This has always bothered me about most implementations of the Sieve of Eratosthenes. Namely, what they produce isn't it.

If you have division operations, or "mod" operations, it's not the Sieve of Eratosthenes, it's just a filter.

Not the same thing at all.

<comment><USER8> It is a sieve. No one claimed it was the Sieve or Eratosthenes.

<comment><USER7> Interestingly, if you look closely you'll notice that I never claimed that this referenced code was the Sieve of Eratosthenes. It seems you just assumed that I thought it was claiming to be, when in fact I know it isn't.

And that's the problem. I've found that when this code is presented people often assume it's intended to be the Sieve of Eratosthenes, and nothing is done to preempt or prevent that misconception. As observed elsewhere, there are now several major threads, discussions, and even proper papers about this, so people _are_ becoming aware of it.

I still meet programmers who think the version shown is intended to be the Sieve of Eratosthenes. Fortunately I now have several on-line references to point them at.

<comment><USER8> If you look closely I never claimed you thought it was...

<comment><USER7> OK, so let's try to be clear about this.

In my experience, that code, pretty much exactly as presented on that page, has, in the past, been called the Sieve of Eratosthenes. You and I both know that it isn't, but I, for certain, know that there have been occasions when it has been claimed to be.

Currently, the version as presented on the Haskell page does not claim that it is the Sieve of Eratosthenes. However, given its history, some people, and in my opinion quite reasonably, will believe that it is, or is intended to be, the Sieve of Eratosthenes.

In my opinion, the people who look after the Haskell page should know that, and should have _something_ there to preempt that mistaken belief. To do so would help to increase people's knowledge. If done well, I doubt that it would hurt, and it might actually help to increase people's curiosity about Haskell.

 _Edit: Just wanted to add that I 've up-voted your comments, because they're true, and they've made me re-evaluate a few things. Thanks._

</comment></comment></comment></comment></comment><comment><USER9> Why is Haskell so slow at this?

As far as I can tell, my Perl implementation at [http://www.perlmonks.org/?node_id=276112](http://www.perlmonks.org/?node_id=276112) is doing something similar with similar amounts of laziness and no optimizations build it. Yet I can produce the first 50,000 primes in the time that this takes to produce the first 10,000. And nobody uses Perl for its speed!

<comment><USER10> I'm not sure, maybe it's just the overhead of having so many function calls and Set accesses? My guess is that the Haskell one could be made quite a bit more efficient if you used a low-level mutable array.

To add another benchmarking data point, I have a simple sieve of Eratosthenes written in Nim using an array that can generate 10,000 primes in less than a millisecond.

<comment><USER9> That is why I compared to an implementation in Perl that was likewise making lots of excess function calls and storing things very inefficiently. This was as close to apples to apples as I could get without putting much energy forward.

Perl gets a lot faster if you sieve blocks at a time, using vec() to manipulate bit arrays. And I'm not surprised that an actually efficient language would be massively faster.

</comment></comment></comment><comment><USER11> You can get another ~3x speedup by implementing the three lines of code comprising the "simple wheel" described at bottom of page 8 of the referenced O'Neill paper.

</comment><comment><USER6> This result was more famously previously published by Melissa E. O'Neill as

[https://www.cs.hmc.edu/~oneill/papers/Sieve- JFP.pdf](https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf)

The Genuine Sieve of Eratosthenes

Harvey Mudd College, Claremont, CA, U.S.A. (e-mail: firstname.lastname@example.com)

And is available on Hackage as:

[https://hackage.haskell.org/package/primes-0.2.1.0/docs/Data...](https://hackage.haskell.org/package/primes-0.2.1.0/docs/Data- Numbers-Primes.html)

</comment><comment><USER12> I agree that this is a more efficient way of generating primes in Haskell than the typical Haskell 101 approach. However, I disagree with the idea that the Haskell 101 approach does not deserve to be called an implementation of the "Sieve of Eratosthenes".

The distinction is only this: when we have found a prime p and are eliminating numbers accordingly, do we consider ourselves only to spend time directly enumerating the multiples of p and crossing them off? Or do we consider ourselves as running through the entire list and going "Ok, ok, cross, ok, ok, cross, ok, ok, cross" (for, for example, p = 3), thus spending time traversing through multiples and non-multiples alike? So to speak, do we jump from "cross" to "cross", or do we walk along through the "ok"s inbetween?

In the former case, each new candidate is worked on only in proportion to its number of prime factors; in the latter case, each new candidate is worked on in proportion to all smaller primes. The former is the more efficient way of generating primes; the latter is (essentially) the ubiquitous, naive approach.

But I don't think one can say the traditional understanding of the Sieve of Eratosthenes draws a strong distinction between these two! Traditional accounts would not explicate any difference between "Jump directly from 'cross' to 'cross' " and "Walk from 'cross' to 'cross', saying 'ok' to everything inbetween". It's not a distinction anyone was traditionally worried about. Eratosthenes certainly didn't.

So I think both of these are deserving of the name "Sieve of Eratosthenes". They're just different approaches to that sieve.

In either case, we say there are primes, to each prime we associate the set of its multiples, we merge these sets into the set of composites, and close the loop of our recursion by noting that the primes are to be the complement of these composites. The difference is, in some sense, arising just from how we represent and manipulate subsets of the naturals (as pertaining to the set of multiples of each prime, as well as their merger into the totality of composites): either as streams of increasing naturals [efficient], or as streams of "In"s and "Out"s [less efficient].

</comment><comment><USER8> Where is it implied on the Haskell home page that it's the Sieve of Eratosthenes?

The variable name? It's a sieve.

[http://en.m.wikipedia.org/wiki/Sieve_theory](http://en.m.wikipedia.org/wiki/Sieve_theory)

</comment><comment><USER13> Upvote despite the article being titled "Haskell programmers are liars". Great decision to use subtitle admins. +1 to bitemyapp for submitting a PR to change "sieve" to "primeFilter" and avoid this in the future.

</comment><comment><USER14> My Scala one using a Java BitSet: [https://github.com/pathikrit/scalgos/blob/9bd0dd81df52a5a410...](https://github.com/pathikrit/scalgos/blob/9bd0dd81df52a5a410c2e6844c5ac0ba62cf544e/src/main/scala/com/github/pathikrit/scalgos/NumberTheory.scala#L19-L26)

</comment><comment><USER15> Even if you know the most optimal solution in terms of computational complexity, it might not be the best thing to put into your code base. There are a lot of other things to balance including (but not limited to) readability, maintainability, probability of correctness, and of course developer time. Considering these multiple dimensions is essential to good engineering.

I'm not saying you shouldn't know the best algorithms for a problem, as this article clearly demonstrates the effectiveness of a more efficient solution. In fact, having better understanding of algorithms and computational complexity makes it safer for you to accurately assess the trade-offs you'll be making by picking slower but simpler code or faster code with more complexity. There is more to consider than just big-O when writing software.

Note: What I'm saying most strongly applies to software with functionality that doesn't exist yet. If there's a reliable library with what you're seeking (such as a way to generate primes), it's usually best to use it.

</comment><comment><USER16> I might be missing something obvious so excuse me, but why not use a heap as a priority queue? It has O(1) find-minimum and O(log n) insert, which is better than a set which is probably some kind of self-balancing BST (I don't speak Haskell).

<comment><USER17> You can use mutable data structures in Haskell but we strive to avoid it except where strictly necessary. To find the "Haskell" version it suffices to add either "Haskell" or "persistent" to the search query for a data structure.

Here's a priority queue library for Haskell, if you'd like an example: [https://hackage.haskell.org/package/pqueue](https://hackage.haskell.org/package/pqueue)

</comment></comment><comment><USER18> Looks the same as in Clojure's lazy-seq documentation [https://clojuredocs.org/clojure.core/lazy- seq](https://clojuredocs.org/clojure.core/lazy-seq)

</comment><comment><USER19> I wrote this with osfameron's help [https://gist.github.com/fibo/1203756](https://gist.github.com/fibo/1203756)

</comment><comment><USER20> Shame on them!

</comment><comment><USER21> That's an overly broad and sensational title. The simplified example on the website certainly isn't representative of all Haskell programmers being liars. It's unfortunate because the article about mis-implementations of the Sieve of Eratosthenes is decent.

Edit: mods, thanks for changing the misleading title.

<comment><USER22> Fortunately there's a decent subtitle and we can just use that.

<comment><USER21> Thanks a lot.</comment></comment></comment>


Gorgeous "Curling Page" JQuery Plugin - <AUTHOR> http://www.elliottkember.com/sexy_curls.html

<comment><USER2> Have you thought about modifying it so that it's not just eye candy, but can also be used for navigation (like proceeding to the page uncovered behind the curl)?

<comment><USER3> aside from that, it would be also nice to put some real content behind the fold (EG: a preview for the next page or something).

</comment></comment><comment><USER4> One question: Why?

<comment><USER5> Well, at least the creator seems to understand the gimmickyness of the effect:

 _But please, use it wisely. If it starts popping up everywhere and becomes "that annoying javascript thing", I'll be very upset._

</comment></comment><comment><USER6> It would be "gorgeous" if it was animated, but as it is it's kind of kitschy. Doubt I'll be using this in any of my projects.

<comment><USER7> Try clicking the "demo page" link - it can be animated :)

</comment></comment><comment><USER8> It would be cool if this could be used to mark important pages on a site by individual users. Sort of like a bookmark, but more user-friendly. Users could quickly see a list of pages they have dog-eared and go back to them.

</comment><comment><USER9> Congratulations Elliott, you've invented a new ad product.

<comment><USER7> I certainly hope not :|

</comment></comment><comment><USER10> Doing this kind of thing is good publicity for his blog.

I won't use this, but I would think about modifying it to my own tastes.

</comment><comment><USER11> He does not bother mentioning that it does not work with internet explorer. It would be nice if ie already was that irrelevant.

<comment><USER7> Thanks - fixed. It now works with IE7. IE6 is a lost cause.</comment></comment>


Ask HN: When is a startup no longer a startup? - <AUTHOR>

I'm wondering if there's an official answer, as well as some sort of community lore about the topic. Specifically, is Facebook or Groupon still a startup? What's the cutoff for when a company exits its innocence and turns into a real company?<p>Inspired by the "most inspirational startup of 2010" post, as well as Steve Blank's "Elves Leave Middle Earth" post. <comment><USER2> There are a few threads about this: <http://searchyc.com/When+is+a+startup+no+longer+a+startup>

The best answer I've seen to this question is "you are no longer a startup when the supplies cabinet is locked."</comment>


Qualcomm's new Snapdragon 865 is 25% faster, comes with mandatory 5G - <AUTHOR> https://arstechnica.com/gadgets/2019/12/qualcomms-new-snapdragon-865-is-25-faster-comes-with-mandatory-5g/ <comment><USER2> Qualcomm-- tying and bundling experts.

Good thing for them that their lobbyist was put in charge of the DOJ Antitrust division. ( [https://www.vox.com/2017/9/27/16376050/trump- administration-...](https://www.vox.com/2017/9/27/16376050/trump- administration-doj-makan-delrahim-antitrust-att-justice-department-merger) )</comment>


America's startups are changing what it means to own a company - <AUTHOR> http://www.economist.com/news/briefing/21676760-americas-startups-are-changing-what-it-means-own-company-reinventing-deal <comment><USER2> I nodded when the article talked about 401k investors and corporate management being strung together with a complex web of middlemen with expensive fees and questionable motivation.

But I started scratching my head when the solution was a web of contracts/repurchase agreements/etc, most of which are secret and poorly understood was presented as the solution.

Let's be real. 80% of this new stuff is there to avoid post Enron regulation, period.

</comment><comment><USER3> "Investors, founders, managers and, often, employees have stakes that are delineated by carefully drawn contracts, rather than shares of the sort that trade on exchanges."

The article doesn't go into more detail about this. What is an example of these carefully drawn contracts? Convertible notes? Something else?

<comment><USER4> I guess it refers to shareholders' agreements and stock purchase agreements?</comment></comment>


Show HN: CoinSocial, a Real Time Dashboard Integrating Prices, Top News, Tweets - <AUTHOR> http://coinsocial.io/#/ <comment><AUTHOR> I built this dashboard because I was often moving between Gdax, Twitter and Reddit. This gives a real time bird eye view of what's going with Cryptocurrency. Appreciate any feedback

</comment><comment><USER2> Add an alert box that will send an email and sms notification if price drops a certain value. That will be super useful. Great work (y)

<comment><AUTHOR> Yes. Text or email alerts are coming. Glad you liked it.

</comment></comment><comment><USER3> I like the realtime price update. Nice job!

</comment><comment><USER4> Is this still working? Just seeing everything as blank.

<comment><AUTHOR> Hi! It's up and working. But I've heard from at least one other person that it's not working. I'm checking. Would please mind dm'ing me your location and browser details or start a chat on the site?

<comment><USER4> It is showing now! I am at home. I may have been at work when checking it, and work blocks a bunch of APIs and different things.</comment></comment></comment>


Sunset: Oracle closes down last Sun product lines - <AUTHOR> http://www.zdnet.com/article/sun-set-oracle-closes-down-last-sun-product-lines/ <comment><USER2> The first round was in January, now September - they will need yet another cut to completely close the Sun chapter.</comment>


Two technologies which are bad for you - <AUTHOR> https://medium.com/@jlouis666/two-technologies-which-are-bad-for-you-160311ad6b24

<comment><USER2> The problem with articles like this is that there is absolutely no call to authority. If I posted some long rant abasing something brilliant, you should have absolutely no reason to believe me should I not provide you with a reason.

What if you, as the author are just a freshman in College, what reason should I have to actually listen to what you have to say?

I used to think that credentials were useless, and still agree that you should never agree with someone because of their creds (proof by intimidation), but lets face it, it should get you in the door. If you've never done anything worth while, I'm not going to waste my time reading/listening/entertaining your rants.

<comment><USER3> > The problem with articles like this is that there is absolutely no call to > authority.

But authority doesn't count in the realm of ideas -- the ideas must stand on their own.

> If I posted some long rant abasing something brilliant, you should have > absolutely no reason to believe me should I not provide you with a reason.

Wait -- which is it? Authority, or reason? Those aren't the same thing.

> What if you, as the author are just a freshman in College, what reason > should I have to actually listen to what you have to say?

That depends. Does he defend his ideas with reason, or authority?

> I used to think that credentials were useless, and still agree that you > should never agree with someone because of their creds (proof by > intimidation), but lets face it, it should get you in the door.

Not in science, not in the age of reason. Einstein wasn't published in 1905 because of his authority -- he had none. His ideas spoke for themselves.

In science, authority is explicitly rejected -- it's even recognized as a logical error:

[http://en.wikipedia.org/wiki/Argument_from_authority](http://en.wikipedia.org/wiki/Argument_from_authority)

"Science is the organized skepticism in the reliability of expert opinion." — Richard Feynman</comment></comment>


How Can You Tell If A CEO Is Lying?  - <AUTHOR> http://blogs.wsj.com/deals/2010/08/11/how-can-you-tell-if-a-ceo-is-lying/?mod=e2fb

<comment><USER2> Oh, so naive. So, you are assuming the CEO actuually represents the company, aznd what they say is relevant. You've already failed on so many levels.

The job of a CEO in modern times is to lie convincingly. If you're still the CEO, you can reap the benefits, but you're stuck with telling the story of why you deserve them, which nobody believes anyways, so its actually a good gig!!

</comment><comment><USER3> there is an old joke: "how can you tell if a salesman is lying" - answer: his lips are moving.

<comment><USER4> That joke has also been successfully applied to lawyers.

<comment><USER5> I've always heard it in reference to politicians.

</comment></comment></comment><comment><USER6> "How can you tell if a CEO is lying?" Easy. If words are coming out, he's lying.

</comment><comment><USER7> Fantastic.</comment>


Show HN: Buildable – Build Apps, Faster - <AUTHOR> https://buildable.io <comment><AUTHOR> Hey Hackers,

We started as a traditional software agency a few years ago and kept seeing problems with the model: prices were too high in order to maintain margins and account for unexpected complexities, scope seemed to be constantly disputed, etc. It didn't work on the agency side or the founder side.

To solve this, over the last couple years we built a system that automates most of the development process. The frontend components and backend services are built to maximize reusability between products on the platform, which allows us to release applications many times faster than traditionally built software. This also drives down the price for founders so it's been a win-win.

I would love any feedback on the landing page messaging to see if it's clear. Or if you have any questions about the platform itself, happy to answer!</comment>


Show HN: Weekendr.io – Curated Friday to Sunday Roundtrip Flights Under $300 - <AUTHOR> https://weekendr.io <comment><USER2> Great to see you still working on this. Bummed that the blog has dropped off at day 6. Looking forward to hearing more lessons from your journey.</comment>


Linux on the OSF Mach3 microkernel (1996) - <AUTHOR> http://bat8.inria.fr/~lang/hotlist/free/licence/fsf96/mklinux.html

<comment><AUTHOR> While reading "LINUX is obsolete (1992)", this relatively unknown article has come to my mind. It's a pretty good read about a real world implementation of a microkernel architecture, and the tricks they had to do to obtain a reasonable degree of performance (migrating threads, collocation...).

Here's a little background. In the 90's, the Open Software Foundation (OSF, now part of The Open Group) was trying to build a common foundation for all UNIXes (back then you weren't a cool IT company if you didn't have your own UNIX OS, ask Microsoft).

As OSF/1, the (supposedly) reference implementation of UNIX, didn't gain enough traction, they started working on OSF Mach. OSF Mach was intended to be a small layer between the hardware and the OS _personality_ , so UNIX companies didn't have to waste effort porting their code for every architecture.

The idea was quite cool (you can think of it as an early form of virtualization), but the initial results were quite disappointing on the performance front (the paper talks about being 40% slower), so they started implementing some tricks that, essentially, broke the microkernel architecture while keeping the modularity. The most significant was collocation, also called in-kernel servers, which put the OS personality in the same, privileged space as Mach, so cross-space messages would become syscalls.

On 1995-1996, the OSF was asked by Apple to build a Linux version for their PowerPC based machines (go figure), and MkLinux, a Linux personality running OSF Mach (which the paper is talking about), was born.

Here's when history becomes a little confusing. We've all been told that modern Mac OS X comes from NeXTSTEP source base, which was a CMU Mach+BSD OS (while MkLinux was OSF Mach + Linux), but if you look at the early code from XNU (OSX's kernel), you'll find an almost unmodified OSF Mach.

I suppose they took OSF Mach, which probably at that point was far more advanced than CMU's, added the BSD bits from NeXTSTEP and finally complemented it with the FreeBSD based IOKit.

<comment><USER2> At the first startup I worked at, we used MkLinux as a way to recycle old (pre-OS X) Macs. One of them was the company firewall for years, another was a Usenet server. It was actually quite a reliable and capable distribution, and of course far better than the crash-prone Mac OS 9 that previously ran on the hardware.

</comment></comment><comment><USER3> I'm amazed at the variety of emulations/ports of various OSes to Mach:

VMS on Mach: [http://dl.acm.org/citation.cfm?id=964616](http://dl.acm.org/citation.cfm?id=964616) \- There's a PS version of this floating around, too.

MS-DOS on Mach: [https://www.cs.cmu.edu/afs/cs/project/mach/public/www/doc/ab...](https://www.cs.cmu.edu/afs/cs/project/mach/public/www/doc/abstracts/dospaper.html)

I'm never sure whether NeXTStep counted as BSD running on top of Mach, or if NeXT built it in to Mach.</comment>


Golang on ARM - <AUTHOR> https://github.com/golang/go/wiki/GoArm <comment><USER2> One of the funniest experiences I had was building an ARM go binary on an x86-64 linux box using a cross compiler (nothing new there). Then, by accident I tried to run the ARM binary on my x86-64 box, instead of on the ARM box. It ran like a normal executable, which confused me until I realized I had installed QEMU-arm, which installed a linux binary format handler for ARM binaries, and it emulated ARM to run my binary. Of course, copied over to the Raspi, it ran fine there too.

<comment><USER3> Did you benchmark performance on QEMU vs bare metal?

</comment></comment><comment><USER4> This is one of Go's best features for me. You can trivially cross-compile statically linked binaries, copy them over to an ARM system and they run fine.

Contrast that with C/C++ - sure you _can_ cross-compile, and I have in the past, but it's a huge pain to set up and who ever remembers the command line options. Those "target triples" aren't even documented anywhere. Plus, good luck building a statically linked C++ program.

Lua might be a decent option too.

<comment><USER5> What about LLVM? Go's support of cross compilation is laughable in comparison to the different LLVM backends. And you can just use the -arch armv7 and -arch arm64 shortcuts instead of those target triples.

Also, FWIW, the reason why Go can even be cross compiled in the first place is because it has platform specific C and assembly code from cgo's runtime so it can support the different architectures/platforms.

Of course, if Go was just an LLVM frontend instead of using gcc then it wouldn't even need the platform specific C code... And it would support a shitton more platforms like asm.js. But I guess Google just hates Apple that much?

<comment><USER6> Russ Cox wrote a great comment[1] on HN about why using the Plan9 toolchain rather LLVM or even GCC was a competitive advantage for them in terms of speed to delivery, control, and iteration.

"Most importantly, it has been something we understand completely and is quite easy to adapt as needed. The standard ABIs and toolchains are for C, and the decisions made there may be completely inappropriate for languages with actual runtimes.

For example, no standard ABIs and toolchains supported segmented stacks; we had to build that, so it was going to be incompatible from day one. If step one had been "learn the GCC or LLVM toolchains well enough to add segmented stacks", I'm not sure we'd have gotten to step two."

"... the custom toolchain is one of the key reasons we've accomplished so much in so little time. I think the author doesn't fully appreciate all the reasons that C tools don't work well for languages that do so much more than C. Most other managed languages are doing JIT compilation and don't go through standard linkers either."

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

<comment><USER7> > For example, no standard ABIs and toolchains supported segmented stacks; we > had to build that, so it was going to be incompatible from day one. If step > one had been "learn the GCC or LLVM toolchains well enough to add segmented > stacks", I'm not sure we'd have gotten to step two."

LLVM now supports both segmented stacks [1] and precise garbage collection with patchpoints [2].

Tweaking support for segmented stacks is quite easy—I added the support for it on x86 Mac. You simply adjust the prolog emission code in X86FrameLowering.cpp and likewise for the other targets.

[1]: [http://llvm.org/docs/SegmentedStacks.html](http://llvm.org/docs/SegmentedStacks.html)

[2]: [http://llvm.org/docs/StackMaps.html](http://llvm.org/docs/StackMaps.html) [http://llvm.org/docs/Statepoints.html](http://llvm.org/docs/Statepoints.html)

<comment><USER8> Yeah, the point is that it wasn't there at that time.

</comment></comment></comment></comment></comment><comment><USER9> It's incredible to run buildall.sh on a recent go repo and see all the cross- compilers get built with no fuss or hassle. There are at least 30 different target platforms I can get to from my ubuntu box with a single command line.

I'm not aware of anything that even comes close to tooling out cross compilation so easily.

<comment><USER10> I do nightly binaries for Prometheus in all the possible archs, while things should compile perfectly there can be small things that prevent things from cross-compiling.

darwin/arm, darwin/arm64, plan9/386, plan9/amd64 and solaris/amd64 don't compile for any of the 11 binaries (e.g. plan9 doesn't work due to logrus not having support for it).

This leaves me with the list at [http://www.robustperception.io/prometheus- nightly-binaries/](http://www.robustperception.io/prometheus-nightly- binaries/) That's still 20 architectures I can compile almost everything to automatically with an ansible+jenkins setup.

<comment><USER11> What is the problem with solaris/amd64?

<comment><USER10> ../../Sirupsen/logrus/text_formatter.go:28: undefined: IsTerminal

The logrus library we use for logging doesn't support Solaris.

<comment><USER12> Looks like it does now:

[https://github.com/Sirupsen/logrus/blob/master/terminal_sola...](https://github.com/Sirupsen/logrus/blob/master/terminal_solaris.go)

<comment><USER10> Good to know, thanks. We vendor our dependencies so it'll be next release before this will work out of the box.

</comment></comment></comment></comment></comment></comment><comment><USER13> Maybe I'm in the minority but I would rather have resources devoted to improving compile times in 1.5+ versions vs. having golang work on arm.

Isn't the best course usually to build a solid foundation, then branch out?

<comment><USER14> Really? I know 1.5 is slower than previous versions, but it's still by far the fastest compiler I've ever worked with.

<comment><USER13> In the global scheme of things it's still pretty fast, but builds on 1.5 take 2x the time of 1.4, it's pretty bad for existing golang users.

<comment><USER15> Why is that a problem for you? With golint / gocode I never have any need for extremely fast compilation. What's your setup like that you're rebuilding so often?

<comment><USER16> Personally, my biggest beef would be that the go developers specifically stood against generics on account of compiler complexity => slow compiling.

It seems they accepted this sacrifice for some other unimportant feature*

*edit: Looks as though the feature they sacrificed performance for was writing Go in Go.

<comment><USER14> Compilation in Go remains lightning fast, again, faster than any other compiler I use; fast enough that it's sane to run the compiler every time I save a file so my editor can highlight the errors.

<comment><USER17> I think there are two schools of thought:

1) Perf for a product should be marked against some shipping benchmark and intermediate regressions don't matter as long as we come below the benchmark at ship time.

2) Perf improvements should be "locked in" and not regressed, unless strenuously justified.

I think the parent is of group (2), where it doesn't necessarily matter that it's better than the benchmark of "against other compilers" but only that Go regressed from their earlier perf metrics for what they believe to be inadequate justification.

I think both groups have valid points. I think (2) is especially good at preventing "perf creep" wherein you continually justify small perf regressions for new features, explaining it away that competitors are doing the same. Eventually, you get to the point where everyone's just slow, but they have no impetus to improve because they're still better than the competition.

<comment><USER16> Group (3), of which I am a member:

If the developers take a specific principled stance against $really_useful_feature on account that it would introduce complexity and thus degrade performance, then compromise this same principle in order to accomplish $entirely_unnecessary_port, it put the obvious lie to their avowed principles.

I don't mind that go compiles more slowly. To Thomas's point, it's still really fast. What I mind is that a good portion of the go community has accepted the lack of generics on the basis of principles that they haphazardly violated in order to scratch the useless but fun intellectual itch of bootstrapping the compiler.

Now that they've done this, they have revealed themselves to be entirely dishonest about their complexity/performance principles, and now the one legitimate objection that has kept generics out of the language has nothing to stand on.

Again, I don't care about performance per se, I care about dishonesty and hypocrisy in the platform's objectives.

<comment><USER14> "Entirely dishonest". "Dishonesty and hypocrisy". In a discussion about compiler performance. Do you understand that framing things like this makes it seem like discussing things with you is intractable?

Absolutely nobody in the universe promised you generics in Go. You may never, ever get them; the longer the language thrives without them, the less urgent they seem.

<comment><USER7> The way the post you're responding to was phrased is indeed hyperbolic. But I think there is a valid point that compiler performance concerns are a pretty unconvincing reason to not have generics, especially in light of a demonstrated high tolerance for compiler performance regressions.

<comment><USER18> Why not consult the go faq to find their reasoning for omitting generics?

> Generics are convenient but they come at a cost in complexity in the type > system and run-time. We haven't yet found a design that gives value > proportionate to the complexity, although we continue to think about it.

The word performance doesn't appear in that paragraph.

<comment><USER19> Complexity in the type system can easily have a negative effect on compiler performance.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Cool! What's the Go memory model look like? Is it stricter than ARM or could possibly working programs be broken when run there?

<comment><USER11> [https://golang.org/ref/mem](https://golang.org/ref/mem)

Btw, in case it's not clear, Go has worked on ARM for the last 6 years, this is not a new thing.

It is the job of the compiler and runtime writer to ensure this model on whatever target platform. It doesn't matter if the target platform has a strong or weak memory model. Correct Go programs written for the Go memory model should work correctly on any target.

Of course that it's possible to write Go programs that violate the memory model but work on amd64, and not on some other platforms. But those are incorrect Go programs (and the race detector has a very good chance of detecting these problems). I will note that it's significantly harder to write these programs accidentally in Go though, than it is to write them in C.

</comment></comment><comment><USER20> How about the support by the LLVM. Shouldn't this be enough?

<comment><USER21> Go already has 2 compiler implementations. There is gc (Go Compiler) and gccgo[0].

[0] [https://golang.org/doc/install/gccgo](https://golang.org/doc/install/gccgo)

<comment><USER5> But LLVM already has a lot of good backends (emscripten, arm, ppc, x86, amd64). Why reinvent the wheel when you could just make Go a LLVM frontend and be done with it?

<comment><USER22> Compile times ? Flexibility over the backend ?

That would be my hunch. I think it makes a lot of sense. Also, note that there is that project which exists : [http://llvm.org/viewvc/llvm- project/llgo/](http://llvm.org/viewvc/llvm-project/llgo/)

<comment><USER7> > Compile times ?

There can be a compile time hit, but you can use FastISel, which is not bad. The compile time hit is mitigated by the fact that you get a far, far more mature series of optimization passes. Since the Go compiler is itself written in Go, more optimizations would make the Go compiler itself faster, further reducing the performance impact.

> Flexibility over the backend ?

Writing to LLVM in no way restricts you to a backend. You simply need a language-level IR that you can retarget to different backends as you would like. This is what Swift, for example, is doing with SIL.

<comment><USER22> > Writing to LLVM in no way restricts you to a backend. You simply need a > language-level IR that you can retarget to different backends as you would > like.

It still ignores toolchain flexibility. Especially given the specific needs of Go's managed runtime.

</comment></comment></comment></comment></comment></comment><comment><USER23> This is for both development on ARM systems (standard go commands, eg: go build, etc) and deploying to ARM systems (setting ARM as a compile target). That said, I'm genuinely curious why anyone would develop on an ARM-based system as opposed to your run of the mill desktop.

I realize that standard towers may be supplanted by their SoC brethren, but so what? Will we all be using iMac-like computers as desktops in the next 36-72 months? Will there even be any differentiation between "regular" desktops with discrete CPUs, memory, etc and the system-on-a-chip variant?

<comment><USER24> Not everybody compiles all binaries they deploy on developer workstations. If you run ARM servers, it makes sense that your build servers are on ARM as well, especially since you should run tests on the same architecture you're deploying to.

<comment><USER25> Well, when your build takes 1min on ARM and 3 seconds on your laptop, it makes sense.</comment></comment></comment>