Hacker News new | comments | ask | show | jobs | submit login

It doesn't really matter whether Google was "in the right" or what the backstory of this case is. It's also not a question of bringing this to the attention of the "right" people at Google. This is an issue inherent to the entire system. The problem is that people entrust their work and often their entire public persona to entities that are guaranteed not to act in their interest.

I don't even think this is about access to decentralized alternatives, after all if you devote years of content to a platform you can probably manage to go through some technical setup pain. Gmail, Blogger, Youtube, Twitter, Facebook - there are self-hosted alternatives out there to all of them, but the big trade-off is that content creators have to shoot themselves in the foot on discoverability if they opt out of the big platforms.

Either at some point we will collectively wise up and re-decentralize or we'll go further down the path we're already on. Our lives ruled arbitrarily by DRM and ToS. I do recognize that I'm personally part of the problem, it's really hard to opt out.




> Either at some point we will collectively wise up and re-decentralize or we'll go further down the path we're already on.

It'll have to get a lot worse before it will get better. This is just another case of the pendulum swinging, and for me the reason to stay away from these centralized services as much as I can. This isn't always easy, especially not when for other people the web is now synonymous with Facebook and Google (and maybe one or two other websites).

Over the years the trend has been a steady reduction in the number of websites that the average surfer uses on a daily basis, this is now < 10 for most people, with a shockingly low 90 or so websites visited per month.

Silo-forming is a logical response to the messy free-for-all that we had (in part Facebooks success is the fact that it limited freedom of expression over HTML), but this has now far overshot the mark where dependency on these very large services is fast becoming an Achilles heel.


As someone who in the past tried very unsuccessfully to get a distributed social network off the ground, I'm frustrated by the utter lack of interest in the silo dilemma. Even when a high profile case of someone getting screwed makes it onto the news (and it recently did!), nobody seems to have a problem with the basics of our way of doing things.

It's stunning to me that we live in a world where the technological infrastructure for a federated web is better than it has ever been, yet at the same time interest is at an all-time low. But I still believe it doesn't take much to start a swing in the other direction. If tomorrow a couple of HN users got together and formed a loosely-affiliated working group for decentralization, there is a decent chance the current momentum could be meaningfully changed.


>It's stunning to me that we live in a world where the technological infrastructure for a federated web is better than it has ever been,

In my opinion, this type of "technical" thinking contributes to misdiagnosing why the majority do not use decentralized services.

Likewise, thinking in terms of technology & software like the "fathers of Internet"[1] have done to try and "solve" the adoption of decentralized ecosystem is misguided. Instead of thinking in terms of the "software stack", think about the economics. Yes, luminaries like Vint Cerf and Tim Berners-Lee are smart but they don't seem to ever address the economics of why a billion people won't choose to run a decentralized stack from home computers. Not just economics of bandwidth and harddrives but also economics of diffused trust, security updates, etc.

My theory on why they don't put economics at the forefront of their pleas for a decentralized internet: their formative years of the internet happened when the entire Internet was sponsored by the government and universities. So to them, it just seems like today's problem can be solved with "technology".

>If tomorrow a couple of HN users got together and formed a loosely-affiliated working group for decentralization, there is a decent chance the current momentum could be meaningfully changed.

I respectfully disagree. I think creating a "decentralized-Facebook" such as Diaspora to be adopted by a billion people is extremely difficult ... because it's a very hard economics puzzle. I'm dismayed that 99% of blog posts advocating for decentralization never deconstructs this factor. It's handicapping our ability to analyze the situation.

[1]http://spectrum.ieee.org/view-from-the-valley/telecom/intern...


> In my opinion, this type of "technical" thinking contributes to misdiagnosing why the majority do not use decentralized services.

A good point, but I don't think it's economics. I believe the issue is more just interest. Even if it were made super easy, most people have no reason to switch. Sure, people who like their privacy want it, but those are the kinds of people who should, in fact, join together and start their own network and stop complaining that the vast majority of people won't join them. Maybe on our biz cards, we could put info to access our private networks, like diaspora, and that would give us an opportunity to promote it when people read it. Most people are sheep. They'll follow the crowd when something interests them, regardless of the technical or economic difficulty. I mean for Pete's sake - why on earth would anyone spend LOTs of money on "fashionable" jeans with HOLES? - But people do.


I really, really hate to admit it, but your points on economic perspective are very good. :-)

I say "hate to admit" because I'm very much a proponent of decentralized services, and wish for more people to use them...but i guess like others my optimism might blind me a tad to the realities of typical/common user behaviors (and expectations), as well as the reasons and sources of those behaviors (and expectations). I guess users of decentralized services can continue to "throw their own parties", but it might mean not everyone will ever go to said parties. Ah well.


> it might mean not everyone will ever go to said parties

It only means that as long as people think "better" technology is the answer. I think the answer, if it comes, will be in the form of a new take on the incentive structures ("economics") involved, which will probably require some new technology, but will not be driven by it. It isn't a hopeless battle, it just isn't one that will be won with technology alone.


But the economics are there. If there is money in centralized solutions that same budget is (theoretically) available for de-centralized solutions.


I am not convinced by the economic argument. RSS died but email survived and thrived - Google has shown willing to replace and kill RSS in favour of waves and whatever, but kept email.

I think this is a matter of consumer preference for and understanding of an operating model.

Many years ago I worked for Demon in the UK and we gave away free email and fee webspace. The email was heavily used, and the webspace (just 10MB behind Apache) was barely taken up and if I remember discontinued.

The point is that back in 95 we could have written clients that stuck "updates" and photos onto 10mb of webspace (retrospectively that would have been an awesome project) - but ... We did not. We as in the technically minded employees did - scripts to upload last nights photos of drinking sessions abounded. But nothing offered to customers

I think Facebook was part of an explanation to consumers that you could "live" on the web. A confluence of Internet access, mobile, computing advances etc etc etc

Everyone understood email because it was an operating model we had analogue guides for. You write a letter, have it to the mail man who took it to its destination.

RSS is the equivalent of people nailing updates to their front door and waiting for people to come round and read it - That is the sensible way of doing this (currently I mail my updates to SF where Facebook puts it on a very very large front door)

perhaps a better economic argument is that email is more efficient - my MTA looks yours up only if I want to send you an email, and your MTA just waits for connections.

In the RSS / Facebook feed world, I need to poll all of my friends front doors for updates, which model starts to gain runaway efficiencies with the more people I am aggregating polls on behalf of. Facebook has already won that race before they started.

If we think the current situation is poor, we have the regulatory response (break up a monopoly) or the capitalist response (write diaspora and ...)

I think email was already in place before mass aggregation came to the web - and its economic model did not tend to a centralised model (if everyone uses Google as the POP3 endpoint, email itself is still decentralised)

But RSS (which covers status updates, broadcast messages, social media) these all economically tend to a single central polling approach. And it was not well established before Facebook era.

As such fighting Facebook will be an economic uphill battle as long as the only difference is where we poll for updates.

Perhaps the calculus will change with an emphasis on privacy. But even so I am posting stuff on my front door. How much privacy can I expect. If I am sending a message to you, it's messging if not it's a public update broadcast? There is no encryption model to send one message to lots of unspecified people (I would need to encrypt it for all my friends individually. Presumably that's what diaspora does). Even so I then have to message you. So why not just cc email.

I have lost my thread here, but perhaps I should say that the key here is the client and regulatory response.

A single client could easily aggregate secure messaging and feeds - but there is not a client to do that.

You could solve the aggregation race by sending mails as a poll trigger.

But you need to replace the client at the same time as requiring Facebook open up.

It seems the move off web browsers and onto apps was a retrograde step in many ways.


PubSubHubBub, a protocol + open server developed by Google back in 2008, already solved much of the polling problem of RSS by adding decentralized push-style updates. But bandwidth costs of feed updates are mostly irrelevant in the economics of Facebook.


> If tomorrow a couple of HN users got together and formed a loosely-affiliated working group for decentralization, there is a decent chance the current momentum could be meaningfully changed.

I hope with you but I fear it's not the case. In the end user convenience will overpower all of the good reasons not to do this and a federated system will - unless it has been specifically designed from the ground up not to have these issues and I'm not sure it can be done - always be slightly less easy to use than one that is just a single silo.

That's the heart of the problem and to date I have not seen anything that even comes close to solving that. In my opinion that's the only problem worth solving in this arena, but of course it is much more fun to go and code up 70% or so of FB in a federated manner with all kinds of usability issues related to the fact that it is now a federated system.

This is a hard problem to solve.


I sort-of agree with you about user convenience, that's what I meant by discoverability issues, but I'm a bit more optimistic that it could be overcome. Absolutely, when people go and have fun coding 70% of FB until the software is able to federate with itself, that's not going to work. But if they would consider it mandatory that their project can talk to other federated projects, that's what I would see as a potential turning point.

The second component that's necessary in my opinion to achieve some kind of real momentum is early adopters that are not from the same techo geek background as we are. There are a lot of these groups that have an acute interest in circumventing silo restrictions, but they're usually not the kind of people I like to associate with - yet if there was one such community with a sufficiently non-deplorable ideology interested in this, it could eventually propel the idea into the mainstream.


Compare with news, arguably a much easier to solve problem. We had a pretty good system in place for federation: RSS. All the big players have done their best to cripple it or outright destroy it to the point where it is no longer feasible. And the overhead for the user was relatively minimal with integration in the browser.


One of the problems with RSS is that it's very one-sided. Facebook capitalized on user interaction, not just a news feed. Diaspora is like a boring Twitter feed. We already have Twitter. Browsers also put no emphasis on making RSS experience any better. They could have devoted a section to feed following. But no. I have to use Liferea for a decent RSS experience.


Every Wordpress blog out there has a comments RSS feed; interaction is certainly not precluded by the technology. If you want to have Facebook-style comments and likes, for example, you can simply have the commenter send the message to the original poster, which will then incorporate it in their feed for everyone else.


The other problem is that backups are too difficult for most people. (Until they lose all those photos of their child, or their dissertation, or their novel, or their business accounts.)

We need some way to communicate the need for backups to people; and we need simple backup solutions. While it's not always a backup, the guy in submitted article would have been okay with Time Machine or similar.


I think main problem here is that Google can get away with not adhering to their own terms of service:

  We believe that you own your data and preserving your 
  access to such data is important. If we discontinue a 
  Service, where reasonably possible, we will give you 
  reasonable advance notice and a chance to get information 
  out of that Service.
It is 'reasonably possible' for Google to give this person access to his data.


(Tedious disclaimer: my opinion only, not speaking for anybody else. I'm an SRE at Google. I don't know what's going on in this particular case, and I don't really want to, because it's probably a huge pile of lawyers.)

> It is 'reasonably possible' for Google to give this person access to his data.

This is not necessarily true. For example, the data might contain material which is illegal to distribute. I'm not sure what can be done in a case like that.


Sure, but unless the guy has a massive stockpile of CP that he was storing on Google's servers, how difficult would it be to let him access his data sans the illicit material? It's not as though a handful of illegal pictures somehow taints every email, blog post, and story he's ever uploaded so as to make them all contraband.


> how difficult would it be to let him access his data sans the illicit material?

It's not my service, and I'm talking about the general case rather than this specific one, but that seems to me like it would be pretty complicated - you'd need some sort of review procedure to determine what material can and cannot be distributed, you'd need to somehow do this while preserving user privacy, and you'd need some engineering work to make all this possible.

A project of that scope could take weeks or months to complete, depending on the amount of data involved.


That sounds like BS.

Presumably the blog was only deleted because there's already some review procedure in place, and it found something that can't be distributed.


You seem to be talking about some specific incident, and guessing about what happened. We're discussing the general case of what you do when you've got a large collection of data that isn't yours, and all you know is that some part of it can't be distributed.


>You seem to be talking about some specific incident, ...

I thought it was obvious from context that I was referring to the specific case in the article.

Anyway, I don't think the general case you're describing makes sense or is very realistic. It's impossible to know some part of the data collection can't be distributed without somebody or something looking at it. Either the person reporting it, or the algorithm flagging it should be able to identify the specific data items that can't be distributed.


> This is not necessarily true. For example, the data might contain material which is illegal to distribute. I'm not sure what can be done in a case like that.

In this case the best decision is probably to stop distributing them to the world but still enable the original owner/uploader to download them.


I'm no lawyer, and don't fully understand these things, but would that not also be illegal distribution?


It can go two ways. If the only thing people really need are basic blogs, videos and chat/email, then in sufficient time, good decentralized solutions will emerge. But if people become dependent on more and more features, then probably we will always have to rely on big companies.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: