tantekbrennannovak - the problem is that any activity could have been posted *somewhere else* and the current stream may just be reposting it. thus something like a "source" element or JSON property for the new AS makes more sense
brennannovakright, I suppose I feel more with Activity Streams than Atom and my suggestion would be that content originally uploaded to Flickr (or anywhere) would considered a "post" verb ---> once ingested to my site it would be a "repost" and then any additional sites that consume my feed would also be a "repost"
caseorganiccreated /WebFinger (+2410) "Created page with 'June 28, 2011 [10:38am] tantek: The IndieWeb does not care about WebFinger - because it doesn't need it. [10:38am] dbounds1: What makes you say that? [10:38am] tantek: becausâ€¦'" (view diff)
dbounds1If the 'indieweb' is only about you interacting with the existing, centralized social web then perhaps XRD and WebFinger don't have a part to play. However, if it's more than that and also involves discovery and interaction with other indieweb resources in a federated way it seems they actually play quite a bit part.
dbounds1I want to be able to link to a local resource on my indieweb site that can retrieve all of the necessary data from the remote indieweb resource the @mention'd user exists to display it in the context of my own website.
dbounds1Yes, I can discover that remove information by parsing a URL extracting the microformats/microdata/etc but if we're avoiding XRD/WebFinger imposing a structure on the remote URL resource we might as well just define a dictionary of remote resources that expose the information in purely machine readable formats.
apparentlymartI think the biggest disconnect in this discussion is that tantek wants to build his own indie site in spite of the rest of the web, exploiting work others already did rather than making them do new work
apparentlymartIf I use Flickr to share my photos but the files themselves are actually stored on a server I own then that's a slightly different idea of hosting that I think still hits some of the indie web use-cases
dbounds1I've noticed recently that some photo sharing services like PicPlz have enabled for auto-syncing of content to your DropBox or S3 account. If a service like that allowed for you to also customize with your own domain name with trickle down into permalinks and shortened URLs, that seems like it would be satisfactory.
lmorchardI had a notion to throw together a lightning talk along the lines of "DNS as homeownership on the web" - talk about controlling your URL space and services like github, tumblr, and posterous who can respond to CNAMEs from your own domain
voxpelliSo while the indie web as you describe it is very URL and content orientated - the federated social web as described during that conference is more activity oriented and therefor less URL oriented
tantekbtw - domain mapping to a hosted provider still has all the problems mentioned here: http://indiewebcamp.com/Why except for identity (since using your domain usually obscures your username on the hosting service)
voxpellitantek: some of those things could be solved by backups mechanisms - other issues are also present in opensource software or other software built or controlled by others. Also - some issues are inherent to hosting. Right+
tantekif you're saying "simple" and ".htaccess" in the same sentence then either you don't understand the full extent of the problem, or you're assuming far too much special technical knowledge on the part of people who want indie web sites.
tantekvoxpelli re: "sounds like it would be possible to build hosted indie web solutions" - maybe - if that's something you're interested in you should pursue it! and please share the designs you come up with - others may want to contribute as well.
tantekthe conclusion was that given that Salmon has been discussed for ~2 years and people still don't have it working, perhaps there's an opportunity for people to build a solution that's simpler and abstract a simpler protocol.
apparentlymarttantek, to be clear, that spec really just provides for the "authentication" bit to remove the cryptographic signatures from salmon. It doesn't actually address salmon use-cases directly itself.
abki__context Â« Why 3 sexagesimal digits to represent the date? It turns out that 3 sexagesimal digits are capable of representing over 500 years of days - plenty overengineered for any human lifetime. Â»