#bretit is still just a manifesto though, which is fairly abstract, so I'm still somewhat confused, but let me know if I have this straight
#brethave you decided upon any existing standards for data exchange?
singpolyma joined the channel
#bretalso, how do you plan to make this useful to people when everyone still uses facebook and twitter currently, aka the monocoulture pitfal http://indiewebcamp.com/monoculture
#bretdepends on what you are wanting to do, a number of us have been experimenting with microformats and semantic htmk data, but there are all sorts of existing social data exchange formats such as activity streams, json-ld etc
#brethave you considered using an existing json vocab standard?
#squeakytoybret, concerning the monoculture, my project can't develop that problem, its impossible. The project defines a "common language", all you need to do, is follow the same standards, and you and me can create a network
#bretwhich is also part of something that the microfomats approach to data exchange struggles with to some degree
#squeakytoyi just think squiso is a really cool idea
#squeakytoybut i am currently doing a lousy job explaining it, i think
#bretprojects like falcon started not with a separate network, but with the goal of owning ones identity online, and thus posting original content to their own site, and posting copies to silos, creating immediate value for people running it
caseorganic, singpolyma, vrypan, wardn_ and spinnerin joined the channel
#vrypanHas anyone worked on the scalability of indieweb proposals? I mean, hosting one's own social stream, etc is nice but maintaing the infrastructure and being able to serve thousands of requests per second whenever your ideas or thoughts get slashdotted (not sure of the modern equivalent ) is not trivial...
#aaronpkserving thousands of requests per second of static html is nearly trivial
#aaronpkbut yea not everyone has a static html site
#vrypanIt's actually about keeping ownership of the things that matter (logic, content) and outsourcing the things that should scale (distribution and interfaces).
#aaronpkcool, that's something I've been thinking about a lot too
#aaronpkthat's also the thinking behind PubSubHubbub
#tantekaaronpk, vyrpan, yes, serving thousands of requests per second of static html is trivial with today's servers / hosts / virtual hosts
#tantekif you can do it with one php script and one flat storage file access, that's also trivial (with today's servers)
#tantek(that's what I'm doing with falcon for viewing any permalink. executes one php file, falcon.php, which determines algorithmically from the permalink which flat storage file to read, and then generates the permalink page accordingly)
#tanteksqueakytoy - also regarding monoculture - I'm not sure you understand how easily it is to fall into it.
#tantekyou claim your project can't develop that problem, and yet, you start with the assumption that "all you need to do, is follow" the new "common language" that your "project defines". that sounds like a new monoculture.
#tantekyou should instead make *your project* follow the common languages of existing efforts
#tantekalso regarding: "I know my project is hugly confusing, and I am working hard to shed some light on it, making it more clear" - the answer to that is selfdogfooding
#tantekselfdogfood by building and deploying bits of your project on your own domain, and then talk about those bits
#tantekif you haven't built it nor deployed it, then advocating it makes little to no sense.
#vrypantantek Ideally, I'd like to be able to serve my entire on-line presence from a computer at home: own the whole thing from iron to bits :-) Practically, this is not impossible, but it really hard for most people. That's why I tried to split the components. That's what the "DLI" is about.
#tantekvrypan - the potential future is to edit/serve your entire online presence from a device in your pocket as well, which asynchronously synchronizes with a static cache "in the cloud" (e.g. akamai) whenever it gets connectivity.
#vrypanI totally agree. "Naming" the components, makes it easier to think about them and letting other people know how a proposed solution fits in their architecture. I'm not saying DLI is the right way to think about it, but if it were, it would make my life much easier if I one that service X is a "distribution component" or that mycrazyservice.io is an "input interface".