TL;DR: DuckDuckGo, a search-engine known for privacy, has a public XMPP service that promises the same level of privacy as their searches. They also have an XMPP chat-bot that will respond to queries over XMPP, but this is less interesting.
I personally am a fan of DDG and use it as my primary search engine. I do wish they'd change their name as it makes it difficult to recommend to non-technical people.
It really bothers me that people are so hung up on appearance.
For any media coverage about Lady Gaga, you are more likely to see column inches dedicated to deriding her appearance than you are to discussing her music.
When the Occupy protests were at their height, there were so many comments along the lines of "They may have a valid point, but no-one is going to listen to them if they dress like that"
All too often I see comments criticizing appearance as being something that indicates their value to be less. frequently it comes in the form of "I know it has value, but you should change the appearance so others can see".
I think this is counter-productive. Appearing business-like may make more people believe you are business-actual, but it also reinforces the attitude that means people judge the business-like as business-actual. It may be good for you but bad for the world. Those who wear the right suits and walk the right walk but cannot actually do the right work can deceive a lot of people.
I think pushing back against this attitude is a worthy endeavour.
Thanks for what you've done with DDG. Privacy is a difficult sell when everyone else is offering "free" services in return for it.
Is there any chance that you could create another brand with a name that I could get non-tech people to use? It could be exactly the same everything except the name. The number of times I've convinced someone to switch until they hear the name...
People have a love/hate relationship with the name. It really resonates well with women in general and K-12. The most push-back on it being too "non-professional" comes from the UK by far.
No immediate plans to change the name or branding, but duly noted! We really do appreciate and consider all feedback.
Consider that the people who have just the "hate" relationship with the name aren't sticking around.
I want to like DDG and I've switched to it from time to time, but the thing that always gets me is that I loathe the branding. I'm really, really sorry, about that and I appreciate what you're doing with DDG, and wish the branding didn't turn me off to a peculiar degree, but Google is such an easy choice and it doesn't get on my nerves.
I know that I'm an outlier in this, but I don't think it's altogether a completely impossible or uncommon reaction to be turned off by the name.
It's not about the name as an abstract concept, or as something you have to look at on the screen. It's saying it out loud that's the problem. It's a perfectly good symbol for representing the concept, but it's not a very good word for using. It's awkward.
I imagine it's easier to soften the Ks with an american accent. For an english person putting two of them in a row like that is just, shall we say, taking the piss.
Perhaps it's not specifically the glottal stop, but there is certainly some articulatory havoc going on when I try to say your search engine's name out loud. I have to bounce my tongue off the roof of my mouth twice in quick succession in a way that's never normally required and it feels quite unnatural.
(Google, on the other hand, is literally fun to say, even though it's a silly word, and hardly professional.)
I can't help associating it with the "ducks" in Old City and those obnoxious quacker things they give everyone. They used to drive me nuts when I was working by their route.
For some reason the name always makes me think of 'toilet duck' toiler cleaner.
The name alone puts me off to a large degree, although the way it seems to go out its way to say "we're not google" puts me off too. Overall I just don't like the way they advertise, I don't feel like it should be appealing to the sort of person I am.
I agree the name is not that great – I know others might disagree – But I once told a friend of mine about DDG, to which he replied: "DuckDuckGo? I would never use a search engine named like that."
I know it's shallow to judge a product/service by its name, but for most people hearing the name for the first time counts as an initial encounter with the product/service, and since that can leave an impression, it matters a lot.
What search engine did that person use? Altavista, maybe, if it still exists? all the others have silly names: Google, Bing, Dogpile, Blekko, Ask Jeeves, ...
I don't think the name is a negative. It's made of simple words that people can spell. It's cute/friendly (just like "google"). It has a mascot. I think the energy that would be needed to "re-brand" to overcome imagined difficulties that I would attribute to more to normal lack of familiarity would be better spent improving the product further to address search coverage and context/language intelligence.
I have found it easy to recommend to non-technical people. (In the early days of Google, I had to spell it for people too... at least this is 3 common words.)
I think the emphasis on converting non-technical people is also often misplaced. Non-technical people don't care about any of the issues that lead to development. The number of people using Skype shows most people don't care about privacy. That doesn't mean DDG's offering is not unique or valuable, it's just that the people to recognize that value will not be the majority by any stretch - but, it never is - and converting people who have the hardest time understanding that value should be a low priority IMHO.
In promoting privacy, DDG captures the union of early adopters, technically literate, and digital evangelists - all groups that are most likely to understand as well as turn around and effectively promote it (for example, by setting the homepage and default search engine after cleaning up a system for a friend)... This is the crowd to keep happy (without raising the barrier to entry either... for example, late adopters will not use bangs or care that you search Hacker News too, but the early adopters appreciate it greatly). These were the same types of people promoting the early Internet to the masses, who barely saw the point in having a computer.
In that vein, one of the best things for DDG, IMHO, would be to make setting ALL browsers as easy as possible (homepage+default search). (I know I'm not saying anything new...) There are add-ons for individual browsers, for example (which I tend not to use, because I like vanilla installations without extensions to upgrade later), and conventional methods (which I prefer, but have been de-emphasized in favor of add-ons), but further-centralizing the process of applying these customizations would be nice. For example, I'd rather download a single native app or portable script (WSH) that was capable of searching out browsers and - through check-boxes - setting their homepage and search (ideally to the SSL search), via the browser-native method (or add-on method), in one pass (usable offline, and ideally at an easy-to-type URL like "duckduckgo.com/tools"). This would help high-turn-over scenarios like tech-support shops, which has the chance to affect the most users but are also under pressure, so want to do the minimum possible (Idea: actively promote to these places).
On a different note, I'm curious how the costs associated with this XMPP service are expected to grow and how it is seen from the business side. If 100000 people started to use it for messaging, would it become too burdensome and be discontinued, or is there a plan for cost-recovery (or is the ddg bot enough of a case)?
The actual English "I searched for it" abstracts the implementation allowing you to switch out the underlying engine without replacing your verbal communication interface.
"I googled it" didn't make a lot of sense for the first 5 years either... I tend to say "duckduckgo it" or "ask the duck" when referring to duckduckgo. It's hard to capture that last 5% of linguistic serendipity, so I'm not sure how it could be any better without sacrificing its identifying uniqueness.
I don't understand the fascination with Google competitors needing to have an easily "verb"ed brand. People never felt the need to verb their search engines before Google. [1] Nor do they now feel the need to verb any other search engine, host, portal, network or huge site like imdb, facebook, wikipedia or amazon. [2]
[1] Hotbotted? AltaVista'd? Lycos'd? Yahoo'd? Asked Jeeves? Did any normals ever say any of those things?
[2] "Tweet" is as close as any other service has come to google-style verbing of their brand by the general public. And that's only the case when you stretch the definition of 'general public'.
I've been using Conformal's Xombrero browser for some time now, and on first run Xombrero offers a choice of search engines, my choice being https://duckduckgo.com/lite
Perhaps DuckDuckGo could acquire a ddg.* domain to make it easier to access?
> I personally am a fan of DDG and use it as my primary search engine. I do wish they'd change their name as it makes it difficult to recommend to non-technical people.
They should really just rename it to Duck Duck Gray Duck.
I went to school in Minnesota and distinctly remember playing Duck, Duck, Goose in kindergarden. This was some years ago, but I would not say there is a lack of controversy in Minnesota.
Sorry if this is slightly off-topic, but I was wondering if anyone could explain the technical reasons why, with minimal modification, we couldn't just replace all electronic messaging systems from SMS to email with xmpp, and forevermore live in a magical fantasy world where email headers, text fees and security concerns don't exist? I mean, it has these things going for it-
1. SSL/TLS embedded in the standard.
2. Easy to set up OTR encryption, (as well as any other standard I imagine).
3. Messages are "pushed" to clients, rather than "pulled".
4. The standard is simple, and servers like Prosody are super-easy to implement (unlike Exim).
5. There are plenty of clients already available. Admittedly it's not something I've researched much, but I doubt it'd take all that much to get Adium or whatever to work like a simple email client, (but with xmpp).
I'm aware of all of the social reasons why such a thing may not work, but I'd be interested to know if it were just a question of getting people to adopt it, were it to exist.
4: XMPP is many things, but it's definitely not simple or easy to implement.
Start with the core spec, RFC 3920. Right away you'll run smack into the problem of XML namespaces, which is a feature that every XML library pretends to support, but with a whole bunch of caveats. Before you can do so much as initiate a session, you will need to search the universe of XML libraries for one that implements a full parser and has good namespace support.
(When I wrote an XMPP library, I ended up using libxml2 because the only platform I care about is Linux.)
Next you'll have to implement encryption (TLS) and authentication (SASL). As with all security-related code, this part of your application is terribly easy to fuck up in a non-obvious-but-user-endangering way. Does your TLS library check that the certificate is valid? Many don't by default. Does your SASL library implement the spec correctly? SASL is complicated and difficult to test, so it's easy for even experienced developers to break authentication for some subset of users.
(I used gnutls and gsasl to do most of the heavy lifting, but still ran into many problems. For example, my library doesn't work with some versions of ejabberd because ejabberd's implementation of SCRAM-SHA-1 was broken: https://support.process-one.net/browse/EJAB-1632).
OK, so you've found a full-featured XML library, you've figured out TLS and SASL, and you can send "hello world!" to another account. Think you're done? Hahaha, no my friend, you're just getting started.
To do anything interesting with XMPP, you need to implement XMPP extensions (XEPs). There are currently three hundred and twenty seven XEPs, indexed at http://xmpp.org/xmpp-protocols/xmpp-extensions/ , and many of them are at least as large as the core spec itself. XEPs cover such important functionality as multi-user messaging, file transfer, voice/video chat, full encryption, avatars, and away messages.
(I decided to skip all that, not do any XEPs at all, and limit my library to simple one-on-one chats because that's all I needed it for. If you're writing something for use by customers, you will not have that luxury.)
And of course, it's all implemented in XML. Hope you've got a sturdy keyboard.
Yeah I would certainly say that building a messaging system of any type with the features of XMPP /from scratch/ would be hard. Then again, just compare the config files of sendmail and exim to prosody or ejabberd. Given that tools for working with xmpp already exist, it does seem a shame to me that it hasn't seen wider adoption. Wasn't Google Wave based on it?
I also love that, to connect to a XMPP server, a client needs to use SRV. Which AFAIK cannot be queried via gethostbyname, getaddrinfo, or any other standard interface. So you need to pull in a nonstandard resolver library, or to fork off `host`.
With that said, John I'm very happy to report that thanks to your library I've been developing an XMPP client for months and have yet to even see any XML.
Requiring SRV essentially allows things like hosted.im to work – using a SRV record for a specific subdomain is probably better than putting in new record types for every protocol cropping up (cf. MX). The fact that SRV records cannot be queried using standard libraries is likely more of a deficiency in the libraries rather than the protocol.
That said, thanks a lot for git-annex & the assistant =)
SMTP is a delay-tolerant store-and-forward system, XMPP isn't. You can't replace all electronic messaging with a system that can't support DTN attributes.
With a statement like that, you're going against decades of experience which says polling doesn't scale. Constant connection setup and teardown is incredibly expensive.
Can anyone please clearly explain what exactly did Google do regarding XMPP? Just stopped using XMPP protocol in their Hangout client? Or disabled XMPP federation on their server? The later doesn't seem to be the case - I can still communicate with the contacts from Google server (though they don't use the Hangout client).
Hangout does not support XMPP, at all. Google Talk still does, but the Google Talk Android app was replaced by Hangouts, they're slowly replacing Talk with Hangout in Gmail, and it's quite likely Talk will be shut down altogether given Google's track record.
I see, so basically Google made a completely non XMPP service (Hangout), and made a bridge between Google Talk (XMPP service) and Hangout. So users of Hangout are cut off from the XMPP network (except for the Google Talk part of it).
So if Google plans to kill Google Talk server and force all its users to switch to Hangout, it means all Google users will be cut off from the XMPP network. Way to go Google, on the road to evilness.
I left Google Talk and switched to another XMPP server a while ago, but a big percentage of my contacts use Google Talk. If Google wants to force all Google Talk users to switch to Hangout - it's really crooked, since all those contacts will be inaccessible.
Sadly, most of the people I would talk to are either on Google or Facebook and neither supports XMPP federation. Where's my federated client-independent IM future?
While Google's recent moves are indeed a backward step, the only way we can fight them is by having open alternatives like this available to people, and by making them as attractive as possible.
There are many practical reasons that people and organisations would rather be in control of their communications, so XMPP (or something, the protocol doesn't matter) is here to stay. The challenge is making that open network worth the big players' time, they currently don't seem to think it is.
You can do that in principle (XMPP servers for the given domain are stored in SRV records, e.g. for my domain praus.net, it's _jabber._tcp.praus.net) but I can't find anywhere that the DDG XMPP server supports custom domains. So you can do it but I think not with DDG just yet.
Google Talk supports XMPP federation and has done so since January 2006.
To deal with an onslaught of spam, Google disabled incoming subscription requests for a short time. During this time, all other XMPP federation features continued to work.
There is no federated client-independent IM future with Hangouts because the Hangout model does not map to instant messaging. It's not about protocol support.
I have not used hangouts, but the name appears to suggest some sort of chatroom? Wouldn’t a XMPP MUC[0] do the trick at least for text-based chats? I can hardly imagine someone wanting to use audio/video all the time anyhow.
Not as simple as that. I actually took a look at the XMPP extensions list to see if I could replicate Hangouts on top of them. You'd need a new audio/video layer with support for centralised DSP, MUC and carbon copies at the very minimum. Not to mention typing notifications (do they work with MUC?), cross-client notification dismissal, automatic client priority assignment (if I'm using a client atm, don't ring all devices, just the one I'm using) and I'm sure a lot more.
Half of these things (e.g. carbon copies) are spec'd out but barely supported.
Hm, most of that is already supported (both in the spec, clients and servers) in user-to-user chats, I don’t know how difficult it will be for MUCs. Audio/Video is the problematic part here, I agree, but at least for me text is a big improvement over the times when I had to call people.
Would it not have been possible to offer a XMPP MUC as a text-based interface to hangouts, to allow ‘legacy’ users to still be connected?
As well as the OLPC extensions for transports to support application and screen sharing.
The X in XMPP is for extensible. I guess the point is Skype doesn't support XMPP or federation, and Microsoft is moving towards Skype and away from their SIP/SIMPLE chat services. Likewise, Apple's promise of an open standard for interoperating with Facetime turned out to be empty.
There was some discussion regarding the Facetime and open sourcing it on HN a while back, I can't find the source this quickly, but it was mentioned that Apple found itself on the barrel end of a lawsuit gun... and that because of that they have not improved Facetime much, nor innovated on it, or published any of the spec.
And as you say - there's a bunch of stuff to support if you go the traditional route and try to bolt on more crap to MUC or <message> stanzas. We're considering just building hangouts on top of "ephemeral" buddycloud channels that just disappear when the last recipient leaves them.
A very valid question. It was probably the outcome of a team meeting (don't we love them?), and one or more people were present with reasons not to take this route. What those reasons were, or whether they were well-founded, we'll never know.
They could publish these reasons to the angry users who are being cut off from their contacts by this. Not doing it shows the low culture of Google in regards to treating users. Evil or not evil, it's simply indecent.
Hangouts also provides information about whether your messages were viewed and syncs chat history across devices whether they were online at the time the message was sent or not.
Message Receipt Notification is XEP-0184 and supported in most clients, though I don’t know how it works in MUCs.
XMPP also has a spec for server-side history storage, that allows for syncing to clients. I don’t know how well it is supported in reality, but understand that there are at least ejabberd modules for the server-side part and a plugin for Pidgin to view this stored history. Not perfect, yet.
I don't care much about receipt notification but chat history sync was probably one of my biggest annoyances with GTalk. I'm glad to see it solved in some way although it is disappointing that Hangouts doesn't support XMPP anymore.
Well, it is being addressed. Ideally, I would like my phone to tell the server to save history of its chats, Pidgin on the desktop syncing these chats over from the server and then deleting them from the server and the server making sure that, if Pidgin is running, it gets messages instantly even if they are sent to/from the phone, either by pushing Pidgin to sync history or ignoring the full JID and always doing a CC to Pidgin.
I guess it is a long way till we get there, though :|
Could you set things up so that a handshake and connection details can be negotiated over XMPP and then have the hangouts-like connection established on a different port. i.e. do something similar to websockets, where connections are negotiated on port 80 and then promoted to a non-standard HTTP port to communicate via a different protocol.
Yes, but do you really believe it has a long lifespan? They've already started replacing Google Talk on Android Phones and it's being slowly replaced in Gmail as well. That relegates it to the same sort of niche status that Google Reader occupied.
Who is "they"? Your city council? Your nation's legislature? The commie-nazi-jewish-muslim-reptilian cabal who puts radios in your teeth?
No major government will forbid effective encryption, because citizens are far more afraid of other citizens than they are of the government. That's why governments request backdoors, or pass legislation permitting warrantless searches.
Think of it this way: your city council will never be able to pass a law forbidding people from locking their car door, because everyone with a car would be screaming about theft. But they could easily pass a law requiring car manufacturers to provide a master key to law enforcement.
This makes sense. By 'they', I meant governments. I always wondered why no mail/im providers support pgp or similar encryption. This means there never will be such a service, since the only master key would be with the end user.
Webmail providers don't provide PGP support because it is not possible to securely implement PGP for webmail. All web-based interfaces are inherently a proxy through a third party, so if you want to read your encrypted mail on the web, you must give your webmail provider the decryption key.
Given this, it's better for webmail providers to not pretend to support secure mail.
DuckDuckGo has no legal presence in countries like that, or any desire to have one. They'll do what is legal in the US, and ignore the complaints of any other country.
So they have a public XMPP server and a bot that gives out the instant answers in their search – I somewhat fail to see how this is groundbreaking or even interesting in any way?
Sure, the bot is nice to play with, but somewhat cumbersome in the long term for me. So why is this great? :)
I can see this being utilized by Google users who still need to use XMPP. With Google removing XMPP support from their messaging services, users will need to find a new XMPP server, and DuckDuckGo fits the bill.
The convenience of Google talk supporting XMPP, for me anyway, was the ability to talk to other people already using Google Talk through the XMPP protocol, and the ability to use XMPP clients.
There are quite a few other public XMPP servers at [1]. Personally, I’ve used jabber.ccc.de for a few years but found it to become unreliable in late 2011 and then decided to host my own, first using Prosody, then ejabberd. Works like a charm.
Being a search engine is not exactly a prerequisite to running an XMPP server. :-)
My server was down[0] for a few hours once and so was my XMPP account. After it was back up, I got a small VPS from a friend to act as a backup/fallback/redundancy-whatever. ejabberd offers that out-of-the-box, meaning that I now have two ‘nodes’ hosting my XMPP domains – if one of them goes down, I either don’t notice at all (if I was connected to the other one) or just have to tell Pidgin to reconnect. s2s connections will similarly just reconnect/don’t notice.
I liked Prosody better, though, and the arcane failure modes[1] of ejabberd still annoy me. So if you get that into Prosody (or did, I didn’t check in the last year or so), I will definitely consider switching back.
[0] Apparently Strato thinks you’re being attacked if a large stream of UDP packets from the 26C3 network hits your server. And I was just using my VPN…
[1] I recently moved that VPS and failed to adapt iptables rules on the other host. Instead of telling me that it couldn’t connect (at maximum log verbosity), ejabberd just did nothing/crashed. I can’t exclude an oversight on my part, but the failure to log anything was rather annoying.
Ah, clustering. Understood, and entirely justified.
Prosody clustering is on the roadmap, but it's a tricky problem to solve properly (and I don't think anyone has to date). We've even had people switch from ejabberd clusters to Prosody, as ejabberd's clustering wasn't working out for them anyway (it seems to be designed more for spreading load than increasing availability).
Our view is that we wanted to get the foundations of the server right before we began tackling such complex problems. Nevertheless I look forward to welcoming you back some time soon :)
If ejabberd starts up, I found it to work rather nicely, so it is not a big problem to me.
But I wish you the best of luck with Prosody, as I said, I really liked it at the time and I trust it only got better :) – regarding the ‘soon’, 2015 is likely an optimistic estimate given Debian release schedules etc…
I was about to say "not packaged for Debian", but apt-cache has proven that to be a false statement. Can't say why I personally (not the GP) went with ejabberd as my first choice; I just picked it at random, and it worked well enough. I will have to look into Prosody. Thanks!
The XMPP network needs more independent servers run by trusted entities, so I welcome this very much (I've been trusting DuckDuckGo with my searches for some time now).
I personally am a fan of DDG and use it as my primary search engine. I do wish they'd change their name as it makes it difficult to recommend to non-technical people.