<p>This is a great idea...extend from without. </p>
<p>I've got a newbie question though. How does diaspora maintain network integrity? What's the federation model? What maintains security and integrity of referential or replicated data?</p>
<p>Specific links to documentation are fine if you don't have time to compose a full answer.</p>
<p>--<br>
Aaron Huslage<br>
+1.919.600.1712<br>
<a href="mailto:huslage@gmail.com">huslage@gmail.com</a><br>
Via mobile device</p>
<div class="gmail_quote">On Mar 9, 2011 9:40 PM, "Samuel Rose" <<a href="mailto:samuel.rose@gmail.com">samuel.rose@gmail.com</a>> wrote:<br type="attribution">> <a href="http://bugs.joindiaspora.com/issues/311">http://bugs.joindiaspora.com/issues/311</a><br>
> <br>> Here's what I wrote:<br>> <br>> "We're experimenting with "plugin" architecture ideas for diaspora.<br>> <br>> We have a simple idea that is based off of the<br>> <a href="http://flows.panarchy.com">http://flows.panarchy.com</a> draft RFC<br>
> <br>> Our idea is to basically keep the "plugins" completely outside of the<br>> diaspora application. We think it could be worth thinking about making<br>> plugins/extensions that work with diaspora across a plurality of<br>
> application layer protocols. "Plugins" could be coded in any<br>> programming language, provided that they conform to the diaspora API<br>> in terms of how they deal with data objects, and the plugins would run<br>
> as a webservice with a variety of access/availability rules. The<br>> advantages here are that the problem of "my diaspora pod does not<br>> support that plugin" is effectively eliminated. As new types of<br>
> content are available for sharing, if special functionality is<br>> required for making the new type of content viewable or usable in<br>> diaspora, it can live as one or more services available on servers to<br>
> accomplish the needed processing. Diaspora instances could be set to<br>> use specific "plugin" services/sources, or could look for next nearest<br>> service available from a distributed registry for instance.<br>
> <br>> I thought that now is a crucial time to think about a scalable way to<br>> allow people to develop extensions for diaspora in parallel. Keeping<br>> them outside of diaspora codebase keeps the code clean and lean and<br>
> easier to refine without the burden of keeping extensions and plugins<br>> up to date because they are tightly integrated into the application.<br>> The extensions can instead be joined via external-facing API that<br>
> supports multiple protocols. What do you all think?"<br>> <br>> -- <br>> --<br>> Sam Rose<br>> Future Forward Institute and Forward Foundation<br>> Tel:+1(517) 639-1552<br>> Cel: +1-(517)-974-6451<br>
> skype: samuelrose<br>> email: <a href="mailto:samuel.rose@gmail.com">samuel.rose@gmail.com</a><br>> <a href="http://forwardfound.org">http://forwardfound.org</a><br>> <a href="http://futureforwardinstitute.org">http://futureforwardinstitute.org</a><br>
> <a href="http://hollymeadcapital.com">http://hollymeadcapital.com</a><br>> <a href="http://p2pfoundation.net">http://p2pfoundation.net</a><br>> <a href="http://socialmediaclassroom.com">http://socialmediaclassroom.com</a><br>
> <br>> "The universe is not required to be in perfect harmony with human<br>> ambition." - Carl Sagan<br></div>