I'm afraid RSS readers aren't very popular, however, and Google was indeed in a better place to change that.
The degree of centralization is directly correlated with its reach. It was decentralized when most people in it were tech savvy, it became centralized as more people got in that are not tech savvy. To make it decentralized again we could 1) expel all non tech savvy people 2) increase the level of tech savvyness 3) create a parallel web where mostl people are tech savvy. I don't see either 1 or 2 happening any time soon. (3) is happening with bitcoin and tor, but as soon as they get popular enough they get centralized again.
Making software centralized makes it easier for non-tech-savvy people to use, as there are incentives to people to make their websites more accessible (larger profits). Decentralized services aren't somehow fundamentally incompatible with usability—its just a challenge we haven't tackled yet.
Decentralized services aren't somehow fundamentally incompatible with usability—its just a challenge we haven't tackled yet.
I don't say it is impossible. Just a lot harder due, for example, to the CAP theorem and friends. But that isn't that important because...
Making software centralized makes it easier for non-tech-savvy people to use, as there are incentives to people to make their websites more accessible (larger profits).
Yes! It isn't a matter of usability but of incentives. By having more tech savvy people you change the incentives, there is less to win by centralization (because they can do it alone) and more to lose (for instance they can't fiddle with it any longer). Also it is less attractive to make a centralization because a larger percent of the users will work around the attempts to control them.
We have a decentralised transport system, and modern vehicles are very sophisticated, but that doesn't mean that every driver needs to be an expert mechanic or embedded systems engineer.
Even so, as cars gets more complicated there is a tendency for centralization. There are more laws and regulations, there is a bigger dependency on the company that designed it, some cars even update their firmware remotely, and so on.
You can't centralize bitcoin, that would be like trying to centralize p2p sharing, the protocol doesn't allow it. An alternative digital currency may emerge that is centralized, or more likely, a single currency exchange will dominate bitcoin. But in reality exchanges would become obsolete if bitcoin really took off (you would just get paid and purchase goods all in bitcoin, no need to exchange to another currency).
You can't centralize the protocol, but you can centralize the most popular exchanges. You still got the protocol down there, but it is wrapped up in a nice centralized single point of failure interface.
Such centralized systems had not existed in Bitcoin before it became popular.
It was mourned, but even then there were people saying it's a good thing. And they turned out to be right, we now have more and better RSS readers to choose from than ever before.
I'd really like to get back into reading RSS, but found it really difficult to manage.
What suggestion would you make for a good, free, cross-platform rss reader?
There's even a hoster that provides ttrss as a service [3].
[1] https://www.zufallsheld.de/2013/11/03/tiny-tiny-rss-centos-n...
I'd recommend using Postgres as opposed to Mysql, as that is what author specifically recommends (mysql support has been a bit subpar)
I tried several RSS readers after Google Reader closed, and Inoreader is the one I've stuck with.
I was happy to pay for a lifetime account. It has a 30 day demo period if you want to check it out before deciding.
BazQux and Pinboard are two simple services that I am extremely happy to pay for, based on their usefulness, reliability, and value.
If I had to pick up a client application I'd choose Feeddemon on Windows.
I would have preferred a browser plugin, but all plugins had a really bad user interface. So I tried RSS tools that are separate from the browser, and settled with QuiteRSS.
Of the desktop client readers, I still favor RSSOwl, but if you have a LOT of feeds, then performance can be a bit of a drag.
In some ways, the web is already decentralizing, or at least moving away from monolithic control by social networks. For younger people, Facebook is basically dead and snapchat does the job.
I doubt we will see significant technological innovation in the next 20 years that matches the scale of interactivity the web brought for the first 20. Maybe VR will be that next step, but even that won't likely change the dynamics of casual web browsing in between work, for example.
So in short, I think that since we've developed all the basics, the state of the web will start to resemble fashion, rather than technological progress.
I suppose the 'Web 1.0' equivalent, if we persist in these ridiculous version numbers, would be Guestbooks.
Why all three? Well, I can't imagine an open hosting protocol without the hosted information being private by default (otherwise the proverbial cat starts outside of the bag, and good luck getting it back in). That implies end-to-end encryption. To do that and still be able to communicate requires a key exchange system -- that's the sharing bit. And to know who you're sharing with requires an identity definition, which has to be stored somewhere. And now we've closed the loop.
There are definitely people working on that problem (I know, because I'm one of them).
> IPFS is a new hypermedia distribution protocol, addressed by content and identities. IPFS enables the creation of completely distributed applications. It aims to make the web faster, safer, and more open.
> The InterPlanetary File System (IPFS) is a peer-to-peer distributed file system that seeks to connect all computing devices with the same system of files. In some ways, IPFS is similar to the Web, but IPFS could be seen as a single BitTorrent swarm, exchanging objects within one Git repository. In other words, IPFS provides a high throughput content-addressed block storage model, with content-addressed hyperlinks. This forms a generalized Merkle DAG, a data structure upon which one can build versioned file systems, blockchains, and even a Permanent Web. IPFS combines a distributed hashtable, an incentivized block exchange, and a self-certifying namespace. IPFS has no single point of failure, and nodes do not need to trust each other.
I mean, pretty much anyone can set up a server to securely host data right now, the main limiting factor is lack of desire, not lack of ability.
Only the identity part is not decentralized but any significantly useful identity anyway needs a solid tie back to the pysical world, as enforcing commitments requires a reasonably reliable ability to trace that identity down to a specific person for legal consequences and expelling harmful actors requires that it is hard to create many fresh identities; I am not aware of any successful identity system that does not ultimately piggyback off of some existing, very centralized sources.
Now, for the sake of argument let's say everyone who wants to host something online has a button that automatically deploys an SSL cert and an https server with domain name, etc. Let's say they throw up a blog on that site. How do they create private posts? That's the critical part, and that's where https isn't just unwieldy, but downright inadequate.
The goal of a network is to facilitate connections between agents, not between topological nodes, and https only provides confidentiality between those topological nodes. If you want everyone to be able to host their own stuff on their own servers, and still retain the ability to have a private post, you need a defined way to share things between those agents. And you could, in theory, write a decentralized protocol for that kind of sharing mechanism, but that requires a sense of who you're sharing things with -- an identity protocol. So you need all three.
Now as you mentioned, identity validation is a very complicated, highly variable problem. Facebook has much lower physical verification requirements than your bank does. There can never be a perfect guarantee that this digital entity is the same as the person you have in your head, in much the same way that you can never truly guarantee that the person sitting next to you at a bar isn't, in fact, impersonating your best friend. You just mitigate that risk as much as possible, which is best done with a protocol that allows people to implement as strict (or nonexistent! can't rule out anonymity) a verification as they need.
And yeah, you could definitely write some protocols that, along with https, accomplishes the above. Arguably that's exactly what Facebook has done (in a closed, sleazy, really not private way). But even if you wrote an open copy of facebook, it's impractical for every single user, or even a large percentage of them, to have their own servers (this, I think, is the fundamental failing of Diaspora). So now you're describing, almost exactly, email over https -- and it still doesn't stop gmail from reading your messages.
Sorry if that's a little meandering, it's been a very long month and I'm exhausted right now, but I wanted to give you at least some kind of response. Does that help clear things up?
A big part of the difficulty is that you truly can't be everything for everyone, but you really need to be something for anyone. If you approach it as a distributed social networking problem (which is most of what I've seen) then you're really missing the indescribably large forest for one specific tree.
The blackbox I've focused on for this protocol is (arbitrary insecure physical bytestream in) -> [box] -> (arbitrary private, authenticated, integrity-verified bytestream out). We use networks to communicate between persons/services/things, not between IP addresses -- the right place to address the problem is between network and application.
It shouldn't surprise you that in practical terms, nobody outside of tech cares enough to use them.
In our Western economic system, the question boils down to:
Can a company make more money based on the concept of centralization or decentralization?
The answer seems obvious (to me).
So for me the answer is not obvious, whether there is more money to be made on the concept of centralization or decentralization. So I think the problem is rather in terms of "amount of user control" instead of centralization or decentralization.
I think you're going to have to explain what you mean by good here, given that you mention there was a good reading platform and it was killed in favour of the monetizable web by the chief web monetizer.
Actually, I think that could have been fixed. If the originating site signed a message, and the each relaying site signed it, then one would be able to calculate a reputation score for sites. Spammy originating sites (or originating domains pretending to be relaying sites) would be easily identifiable, and thus blockable.
"Here is why it won't work.
(X) Requires immediate total cooperation from everybody at once
(X) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
(X) Lack of centrally controlling authority for email
(X) Dishonesty on the part of spammers themselves
and the following philosophical objections may also apply:
(X) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
(X) Blacklists suck
(X) Countermeasures must work if phased in gradually
(X) Why should we have to trust you and your servers?
Furthermore, this is what I think about you:
(X) Sorry dude, but I don't think it would work."
Recall that the way Usenet works is that each site gets its new feeds from one or more other sites.
Imagine that I'm site A, connected to sites B and C. B is connected to D and E; C is connected to D, F & G. Whenever a user at a site submits an article, that site attests 'this message was sent via site X.' Whenever a site sends a message to another site that it received from somewhere else, it attests 'this message was sent via site X.' As part of the setup process, sites exchange signing keys (recall that Usenet peering was fairly static, something arranged by email).
So, any messages local to Site A don't (need) any attestation: they were generated locally, and read locally. Any messages submitted to Site B and sent to A are provably from Site B (and A would in fact reject any message claiming to be from Site B but without a signature). Likewise, any message submitted to Site E would be signed by E, then signed by B, then arrive at A. In the normal course of events, A doesn't care about Site E at all; he cares about the quality of his feed from B.
Say a spam arrives at A. He knows that it didn't come from C, because it's signed by B. So he returns it to B, stating, 'yo, police your users!' B can see his own signature on the spam, so he knows that he can trust the origination of the message from his point of view (whether it's his own user, or one from Sites D or E); in fact, B could automatically forward the spam notification to the originating site if it weren't his own.
Let's say that B is actually malicious, and has invented a hundred fake sites that he pretends to forward messages from. I don't care: any message I get from B is signed by B: if I receive enough spams from him, I can choose to just refuse articles from him.
> (X) Requires immediate total cooperation from everybody at once
Some solutions do require complete cooperation. Given that Usenet's effectively dead, is an example which kills Usenet and replaces it with Usenet-Prime all that different?
> (X) Anyone could anonymously destroy anyone else's career or business
Completely and totally wrong, since in the model I'm talking about reputation is local to my site, not shared.
> (X) Lack of centrally controlling authority for email
Nope: no centrally-controlling authority is needed: each site only cares about the relationships it has established, and doesn't care about downstream relationships ('police yourself!').
> (X) Dishonesty on the part of spammers themselves
Nope: dishonesty doesn't matter because each site only cares about the quality of the feed it receives from other sites. A dishonest site will have a poor-quality feed, and may be disciplined by being ignored.
> (X) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
Seems quite practical to me. 'We've not bothered to try' doesn't count as a proof of impracticality.
> (X) Blacklists suck
Better than whitelists, no? At some point one has to refuse to do business with bad actors; that's a blacklist.
> (X) Countermeasures must work if phased in gradually
Why? As noted, Usenet is basically dead by now; how would killing it and recreating a new, more trustworthy one not have been better?
> (X) Why should we have to trust you and your servers?
I think maybe you thought that I was proposing some sort of centralised reputation system, which would indeed be crazy.
So you're really just doing current antispam, with some additional identification which may or may not be respected (its value relies in forcing manual labor on initial key exchange) and may or may not be scalable (say you put a new honest mailserver online -- are you going to statically exchange keys with all other servers out there? And how do you verify a key is still valid at any point? Are you going to pull something out of DNS? this sounds familiar...). Hardly a silver bullet IMHO, sorry.
> Completely and totally wrong, since in the model I'm talking about reputation is local to my site, not shared.
It doesn't matter: you're a stolen key away from suffering. If I get your key and start signing spam with it, sending it all over the place, you'll soon be overflowed by "yo!"s, you'll have to regenerate keys, rebuild trust (a process you've forced to be slow), and your mail won't go through for days or weeks. The typical exactness of caching algorithms will ensure that minor servers will still be "yo!"ing you for months or years, and again your mail won't go through.
We really have no idea how many private keys get stolen every day. They are just not deployed unless they produce valuable activity (accessing a control panel, signing a malicious driver and so on). Spamming is an immediately-valuable activity, so they would become prized loot overnight. Also, we've seen enough attacks on HTTPS and other "secure" implementations by now, that we should know signatures are not a panacea.
And all this effort just to add "another signal" to the pile of checks we already do...
> Better than whitelists, no?
They are effectively the same thing, which is why the following option in the list is "Whitelists suck".
> (X) Countermeasures must work if phased in gradually
Why?
Are you going to have "email switch day"? Good luck with that. Look at IPv4 vs IPv6, email is on that scale.
EDIT: apologies, I see you were concentrating on NNTP. However, I don't think the two worlds are particularly dissimilar -- NNTP just never reached the scale and criticality of SMTP, at which point your solution becomes basically unmanageable.
Setting up NNTP peers has always been manual, and one has always gotten one's newsfeed through one's peers which is why this can work; as your edit noted, this can't work for SMTP because it's a different model.
> If I get your key and start signing spam with it, sending it all over the place, you'll soon be overflowed by "yo!"s, you'll have to regenerate keys, rebuild trust (a process you've forced to be slow), and your mail won't go through for days or weeks.
And for NNTP that would be okay.
Solving the SMTP spam problem is something else entirely, and I wouldn't want to taken on that burden. But Usenet could have been saved.
In addition to that you failed to understand what signatures do: there is no way you can have sign a message with anybody else signature. And it doesn't require immediate cooperation if a signed message with a good reputation is used as one of several spam signals. You want to discuss viagra? Well better sign your message with a public key and have a track record of not being a spammer.
Blacklists are the de facto solution that we implemented because using that list prevented any consensus of any other method of combating spam.
Unless, of course, you have a closed system everyone cooperates in; which is nothing like current email and cannot be rolled on gradually.
Honestly now? That list hurts because it's true, and you know it. You cannot wipe out spam without losing the decentralization element built into current protocols. Your "solution" would just add yet another "signal" to the long list of hacks spammers routinely implement.
(Not that I really care: I use gmail, trading my privacy for some of the best antispam systems money can buy, and I'm happy enough. I'm just a bit too old to still believe spam can be fixed, or that "webs of trust" can work at significant scale.)
I was writing about NNTP, not SMTP—they are different.
> You cannot wipe out spam without losing the decentralization element built into current protocols.
NNTP was never decentralised like SMTP is. Each NNTP site had a very limited number of feeds, set up on a social basis. There was no concept that anyone could submit articles anywhere; rather, users submitted articles to their local site, which forwarded them on. In this environment, cutting bad feeds out would have worked (or at least, kept spam to a manageable level, which is all anyone really cares about).
Also, the biggest problem with PGP-type signing as a mechanism to control spam is not whether you can spoof the signature or not, it's that there's nothing in it that stops the spammer from generating a new identity once the current identity is tarnished.
And a central authority is not really all that decentralized, is it?
Nope. Each site would be its own verifying authority. All I care about as a site is that the sites which feed me are responsible for what they send me; all each of them cares about is the same. If any one site gets bad enough, I'll start to reject their articles.
Which is why I was writing about Usenet☺
Controlling spam in general is a much tougher problem, but in the directed cyclic graph which is Usenet, it could have been done.
It's not unthinkable that Facebook will be the top destination 20 years from now if they are (1) successful with internet.org and (2) first-to-market with a viable virtual reality product.
Does Economies of scale outweigh the economic surpluses gained from a more competitive economy? Well, that's something one should ask an ivory tower Economist.
See also: Google's increasingly long list of discontinued products, many of which were acquires from burgeoning young businesses.
Ask an economist and you'll get different normative answers of how we should craft policy, but the positive answer will be the same across the board: it has happened with clothing manufacturing, publishing, radio, TV, food production, etc. and is now happening with the internet. A nascent and initially fragmented medium/industry attracts investment and develops standards; large conglomerations begin to form and M&A smaller players to gain market share, leading to a saturated market of heavy-weight players.
And PCs - it started out as a decentralized market between Apple, Commodore, Tandy, Atari, Osborne, etc, but then centralized under IBM before being decentralized again with IBM clones like Dell, Compaq, etc. That in turn forced the centralization of the OS market under Microsoft (driving out Apple, CP/M, Acorn, Atari) and microprocessors under Intel (driving out Motorola and MOS technologies).
I think it's more accurate to say that the point of centralization moves up and down the value chain based on technological developments, market deals, and corporate strategy. When things get too centralized, a savvy entrepreneur will come in as a small-time complement, then find a way to encourage competition and commoditize his complements, riding the wave to a very prosperous monopoly. When competition becomes too intense in those markets, the bigger players will start eating the smaller players, and eventually the market consolidates.
These networks with small world properties strike a highly pragmatic balance. They are far more robust to insult when compared to centralized networks (though not so much as random) while having much more efficient propogation of information than in more random networks.
However, as technology progresses, we might reach a point where "distributed" can be sufficiently efficient.
no self-respecting third-world intellectual is going to be satisfied by a catered whitelist of websites they can access. to me this seems like an attempt to repeat what we did with confusing "the web" with "the internet" by having third world people confuse "facebook" with "the web"
It doesn't matter what intellectuals are satisfied with, the internet (like TV and Radio) will be driven by what the mass-market consumer wants. If they can get all they need from Facebook for free (running a business & talking to friends and family), then why pay more to develop a network that they don't want?
[1] http://qz.com/333313/milliions-of-facebook-users-have-no-ide...
so what I predicted has basically already happened. sigh.
Blogs suffered from the inability to provide a good reading platform, which is why the death of Google Reader was so mourned. GReader, not G+, was Google's best weapon against Facebook (with proper development, not stagnant as it was).
It is easier to add features to centralized architectures, but it does not mean the death of distributed protocols. I do believe a distributed publishing platform will be born sometime in the future. It is unthinkable that Facebook will still be the top destination, say, 20 years from now.