Having a place you could publish your own information to be linked to and to link to other places is what HTTP was designed to do (and gopher before it). You can also have control over your own data if you're posting it on your own web site.

What HTTP doesn't do is force (or even request) the sites you link to to include your content, or to link back to you. But it's good that it doesn't force other sites to link or to include your content: For example, would you want your own site to be required to link to a casino site just because they linked to you? Or to include their casino-related content on your post about network reorganization?

The notification issue has been approached in a couple ways under HTTP already, too. The dominant techniques seem to be well-summarized on Wikipedia's Linkback article.

Maybe just one of those frameworks in conjunction with the ability to simply and easily add HTTP pages (e.g. blogging + a personal wiki) would fulfill the program you've set out here? You'd also want to combine them with a standardized backup mechanism so that people could, as you suggest, make local copies of their data for safekeeping in case of bad disaster. one-click tarballs of the relevant data? (i know you want me to say "git"

Making it easy for the human involved to respond to one of the Linkback mechanisms (e.g. by allowing a well-filtered linky comment to show up, or by rejecting it as irrelevant or spam) would probably be a necessary component.

I think it's important to frame the issue the way you have, though: I think the issue is autonomous control over data, and it's an important one.

--dkg

I never considered how similar the Linkback concept was to the one I am proposing here.

The Wikipedia article refers to the web server that we want to post content to as the "linked server" and the server under our control that we will adding the content to as the "linking server."

I've never used any of the linkback protocols - but it appears that the linked site can choose which linking site they want to publish and what content from the linking site post they want to show (and I don't see why you couldn't display it looks as if the post was made to the linked site itself). That's very exciting.

I had in mind a different user experience and also was thinking about slightly more structured data. I still think it could work with linkback.

All common web applications have forms which allow you to post data to that particular web application - comments to blogs, workshop proposals, sound files, ride board request, job post, etc. etc.

The user experience I was angling for was: every time you get a form asking you to fill out some kind of data, you could either fill out the form and have it saved to the server running the web application (as we usually do now) or you could optionally enter the URL of your content provider and click submit and the server running the web application would re-direct you to your content provider and instruct the content provider to display a form with the proper fields displayed. You would then, authenticate to your content provider, fill out the form on your content provider server, click submit, save the data on your server, and then the linkback mechanism could be triggered to notify the original server.

The linkback approach really does capture the essence of this idea - it would be great to see it expand beyond blogging and comments.

--jamie