Halfway There!

Posted on August 10, 2010 and filed under Plexus.

Yes, things have been quiet.  But not because of any lack of activity. Indeed, the code elves at Casa Plexus have been toiling away both night and day, writing the various modules that make up the prototype of Plexus.  At this point the prototype is roughly half complete.  There’s an API which uses SMTP and POP3 to interact with Plexus – this so that I wouldn’t need to spend time writing client software to interact with Plexus.  There is a module to manage the Plex, and a jCard mailed to Plexus will end up in the Plex.  When Plexus starts up, it walks through the Plex, and instances the appropriate listeners – though the only listener implemented at present is the feed reader.  When things are listened to, those are passed up so that they can be grabbed a convenient POP3 mail client (I’m using Thunderbird).

It all seems to work.  It is rickety in the way of all prototypes, but it does work.

The next half is to write the modules which handle the sharers.  This is going to take less time (hopefully) because so much of the structure is already in place.

If current plans hold there will be a code release of the prototype to a Mercurial repository sometime before the 18th of September.  Then the real fun begins.

No comments.

Use Case: Facebook

Posted on July 28, 2010 and filed under Plexus.

Like it or not, Facebook isn’t going away.  Having just passed half a billion members, it looks to become a fixed star in the Internet firmament.  Nothing is assured – least of all in the world of social networking – but it seems to be the default social networking technology for grandmothers, teenagers, and mobiles. Which means we must learn to live with it.

Since I quit Facebook at the end of May, I’ve been getting significant pressure from one of my friends – off studying Tibetan Buddhism with the Dalai Lama’s crowd in Dharmsala – to rejoin Facebook, so that I can keep track of his comings and goings, his pilgrim’s progress, and the conversations all of this has engendered within his social graph.  And, to be honest, I do feel as though I’m missing out on something.

This morning I came up with a solution.  We’ll call it ‘Safebook’.  Safebook is a front-end to Plexus.  You tell Safebook who you want to connect with on Facebook, and it goes and creates a Gmail account for this purpose, then creates a Facebook account with an assumed name – linked back to the Gmail account – handles all the credentialing, authentication and profile generation, then connects to the friend’s account, sending them a message something like, ‘Hi – this is really Mark Pesce, so friend me!’

Once that’s done – and once the friend has accepted the request, Plexus handles the rest.  Plexus knows to use its Facebook interface – and specific credentialing information – when you want to talk to that friend.  Plexus is always listening to that account, so that if your friend posts anything, you can be notified of it.

Safebook allows you to do this for all of your Facebook connections, each connected via a single-use account.  This means that your social graph is never revealed to Facebook (which is important), but you can still maintain connections through Facebook to your entire social graph (which is equally important).

So, will this work?   Thoughts?  Suggestions?  Improvements?

9 comments.

Another kind of jCard

Posted on July 20, 2010 and filed under Plexus.

Here’s the jCard for the New York Times

{ "vcard" : [
	{ "class": "Public",
	"fn": "NY Times",
	"uid": "b636257c-93ca-11df-a183-7c6d628f0c21",
	"photo": "http://graphics8.nytimes.com/images/misc/nytlogo379x64.gif",
	"connections": [
		{ "twitter": "nytimes", "id": "Twitter" },
		{ "feed": "http://www.nytimes.com/services/xml/rss/nyt/HomePage.xml", "id": "US Home Page" },
		{ "feed": "http://www.nytimes.com/services/xml/rss/nyt/World.xml", "id": "World" },
		{ "feed": "http://www.nytimes.com/services/xml/rss/nyt/US.xml", "id": "US" },
		{ "feed": "http://feeds.nytimes.com/nyt/rss/Business", "id": "Business" },
		{ "feed": "http://feeds.nytimes.com/nyt/rss/Technology", "id": "Technology" },
		{ "feed": "http://www.nytimes.com/services/xml/rss/nyt/Sports.xml", "id": "Sports" },
		{ "feed": "http://www.nytimes.com/services/xml/rss/nyt/Science.xml", "id": "Science" },
		{ "feed": "http://www.nytimes.com/services/xml/rss/nyt/Arts.xml", "id": "Arts" },
		{ "feed": "http://www.nytimes.com/services/xml/rss/nyt/Magazine.xml", "id": "Magazine" },
		{ "feed": "http://www.nytimes.com/services/xml/rss/nyt/Opinion.xml", "id": "Opinion" } ],
	"rev": "2010-07-20T16:55:00" } ]
}

This isn’t exhaustive – the Times offers many different feeds – but it makes the point clear: jCards aren’t just for individuals.

1 comment.

Amazing

Posted on July 17, 2010 and filed under Plexus.

I’ve spent the last few weeks talking to a lot of people – including all of you. Many of you have come up with amazing suggestions for Plexus.  Some of you have gotten a song-and-dance form me about thinking about front-ends to Plexus.  Which leads to even more amazing suggestions, and ideas.  It seems that just opening the subject to conversation produces an almost brain-melting rapid-fire exchange of ideas.  Thank you all very much for that.  And if you have more (I’m sure that you will) please don’t be afraid to share them, here, or privately, or wherever suits you best.

On the implementation front, there is a very basic SMTP-based API module, which can receive jCards and hCards as attachments in emails.  For the moment, only jCards are handed off to a still embrionic Plex for insertion.  The Plex is the focus of activity right now.  Once that’s done, it should be (relatively) easy to move on to the Sharers and Listeners.

Once again, thanks for all the incredible input.

No comments.

jCard format revisions

Posted on July 14, 2010 and filed under Plexus.

No file format survives its first encounter with database schema.  As designed, jCard format was a bit wrong – more a list than a dictionary.  I’ve taken out some of the spurious syntactical elements, and added a new keyword, ‘connections’, which represents the list of connection points.

The new jCard looks like this:

{ "vcard" : [ {
			"fn": "Mark Pesce",
			"uid": "6fa459ea-ee8a-3ca4-894e-db77e160355e",
			"nickname": "mpesce",
			"photo": "http://upload.wikimedia.org/wikipedia/en/3/3d/Mark-cafelife.jpg",
			"connections": [
				{ "twitter": "mpesce", "id": "Twitter" },
				{ "feed": "http://blog.futurestreetconsulting.com/?feed=rss2", "id": "The Human Network" },
				{ "flickr": "hyperpeople", "id": "Flickr" },
				{ "delicious": "mpesce", "id": "del.icio.us" } ],
			"rev": "2010-07-11T11:39:00" } ] }

Several of you have done as you’ve asked, and submitted your own jCards. Since I asked for them, I will update them appropriately, and post the updates.

23 comments.

hCard and jCard — and a request

Posted on July 13, 2010 and filed under Plexus.

The consensus opinions seems to be that the XHTML version of the card should remain named ‘hCard’, in order to avoid further muddying the waters – and also to entice hCard devotees to give Plexus a whirl.

John Allsopp suggested ‘jCard’ for the JSON version, and I rather like that. Henceforth pCard is dead – long live hCard and jCard!

Now an important request – I need jCards. I am writing the Plex modules this week.  The more jCards i can feed it, the happier I will be about the durability of these modules.  So if you could please write a jCard for yourself – or for someone else, I’m not picky – and either email it to me or post it as a comment on this thread, I’d be very much obliged!

This will probably also be an opportunity to learn jCard format, and for me to learn what needs documenting on the wiki.

9 comments.

hCard or pCard?

Posted on July 12, 2010 and filed under Plexus.

John Allsopp, the man who (literally) wrote the book on microformats, has given pCard format a once-over.

His suggestion? “Why not simply leave it as hCard?”

The differences between pCard and hCard format are – at this time – entirely semantic. Something is a pCard because it’s to be used with Plexus. Something is an hCard because it’s to be used with some other software. That’s pretty much it. Those semantic differences are significant – we are doing things with the url field that people wouldn’t think to do with normal hCards – but they won’t cause a parser to barf. Much.

If we do call it hCard, we inherit all of the apps and websites which use hCards. Not a bad thing. That said, should the JSON format should still be called pCard, to differentiate the two?

So many questions.  What should we do? hCard or pCard? Please cast your vote here!

8 comments.

pCard format (XHTML & JSON)

Posted on July 11, 2010 and filed under Plexus.

I’ve spent a few days thinking about pCard format, here are the initial results of my work…

This is the XTHML microformat, which is completely compatible with hCard microformat:

<div class="vcard">
<span class="class">Public</span>
<span class="fn">Mark Pesce</span>
<span class="nickname">mpesce</span>
<span class="uid">6fa459ea-ee8a-3ca4-894e-db77e160355e</span>
<img class="photo" src="http://upload.wikimedia.org/wikipedia/en/3/3d/Mark-cafelife.jpg" atl="Mark Pesce" />
<a class="url" href="twitter:mpesce">Twitter</a>
<a class="url" href="feed:http://blog.futurestreetconsulting.com/?feed=rss2">The Human Network</a>
<a class="url" href="flickr:hyperpeople">Flickr</a>
<a class="url" href="delicious:mpesce">del.icio.us</a>
<span class="rev">2010-07-11T11:39:00</span>
</div>

Which renders to the equivalent in JSON:

{ "vcard" : [
	{ "class": "Public" },
	{ "fn": "Mark Pesce" },
	{ "nickname": "mpesce" },
	{ "uid": "6fa459ea-ee8a-3ca4-894e-db77e160355e" },
	{ "photo": "http://upload.wikimedia.org/wikipedia/en/3/3d/Mark-cafelife.jpg" },
	{ "twitter": "mpesce", "id": "Twitter" },
	{ "feed": "http://blog.futurestreetconsulting.com/?feed=rss2", "id": "The Human Network" },
	{ "flickr": "hyperpeople", "id": "Flickr" },
	{ "delicious": "mpesce", "id": "del.icio.us" },
	{ "rev": "2010-07-11T11:39:00" } ]
}

Then there’s the XHTML microformat for a Private pCard (contains more sensitive contact information):

<div class="vcard">
<span class="class">Private</span>
<span class="fn">Mark Pesce</span>
<span class="nickname">mpesce</span>
<span class="uid">6fa459ea-ee8a-3ca4-894e-db77e160355e</span>
<img class="photo" src="http://www.abc.net.au/unleashed/images/mark_pesce_100.jpg" atl="Mark Pesce" />
<abbr title="1962-12-08" class="bday">Dec 8 1962</abbr>
<div class="tel"><span class="type">Cell</span>
<span class="value">+61 418 653 187</span></div>
<a class="email" href="mailto:mark@markpesce.com">mark@markpesce.com</a>
<a class="url" href="feed:http://blipvert.markpesce.com/?feed=rss2">Blipvert Blog</a>
<a class="url" href="steganoflickr:mpesce">How Not To Be Seen</a>
<span class="rev">2010-07-11T12:05:00</span>
</div>

And its JSON equivalent:

{ "vcard" : [
	{ "class": "Public" },
	{ "fn": "Mark Pesce" },
	{ "nickname": "mpesce" },
	{ "uid": "6fa459ea-ee8a-3ca4-894e-db77e160355e" },
	{ "photo": "http://www.abc.net.au/unleashed/images/mark_pesce_100.jpg" },
	{ "bday": "1962-12-08" },
	{ "telephone": { "type": "Cell", "value": "+61 418 653 187" } },
	{ "email": "mark@markpesce.com" },
	{ "feed": "http://blipvert.markpesce.com/?feed=rss2", "id": "Blipvert Blog" },
	{ "steganoflickr": "mpesce", "id": "How Not To Be Seen" },
	{ "rev": "2010-07-11T12:05:00" } ]
}

This draft of pCard format is not meant to be exhaustive. I’ve left out some of the existing hCard data in these examples, but they could easily be put into the pCard, as the format is entirely backward-compatible. No changes need be made to hCards to support pCards – the differences are all semantic, not grammatical.  I know this because I ran these two pCards through the hCard validator, and they came up as 100% validated.

Everything here is probably fully self explanatory except, in the case of the XHTML pCard, for the URL accessor methods, which don’t read ‘http:’, as they normally do, but instead read ‘twitter’ and ‘feed’ and ’steganoflickr’, etc.  In this case, the accessor method has been replaced by the service name to be used as an accessor.  There is a one-to-one correspondence between service names and sharer/listener modules.  This is the place where a specific module is bound to a particular entry on the pCard. In the case where a complete URL is required, the URL accessor method is provided after the service specifier.

I will post this all to the wiki presently so that we can start to explore it.

11 comments.

API Thoughts

Posted on July 10, 2010 and filed under Plexus.

The Plexus API has to do three things:

  • Provide an interface by which client/front-ends can talk to the Plex
  • Provide an interface for data sharing (the Sharer)
  • Provide an interface for the ‘connected data stream’ (the Listener)

There are any number of approaches that could be taken to provide an API.  Most web services provide REST-ful APIs to their services.  Some use a version of SOAP, or XML-RPC.  All of these services use HTTP as a transport layer – which makes sense, as it is the transport layer of the Web.  But there’s no fundamental reason that the Plexus API needs to use HTTP as its transport.  Since a Plexus client could be Web-based, or a custom application (perhaps running on a mobile), the transport needs to be flexible.

For this reason, the Plexus API will be modular.  The basic reference implementation will include an API (most likely REST-ful), but the prototype will be designed with an API that uses POP3 for the Listener interface, SMTP for the Sharer interface, and email command-and-message-passing for the Plex interface.  This means that an email client can be used for prototype testing.  That’s a big win.  This will be ‘debug mode’ for Plexus, baseline functionality that is included the prototype.

What kinds of APIs should be developed for Plexus?

2 comments.

The TODO list

Posted on July 8, 2010 and filed under Plexus.

I’ve started a basic list of things that need to be designed and implemented in the prototype.  It’s on the wiki.

Feel free to contribute.  But remember, KISS.

No comments.