Testing one two three

February 14, 2011 7:01 am via Plexus ModuleReplyRetweetFavorite

@mpesce

Mark Pesce

This tweet was sent from plxcli.py to Plexus, which correctly dispatched it to the Twitter sharer module.  Which means Plexus sharers are now (barely) working.  Which means, nine months after I thought it all up, the basic structure of Plexus has been realized.

Whee!

First, download the new repo.  Now go to the directory.  You’ve got a few tools available to you to help build your Plex.  If you do have a Gmail account (with associated Google Contacts), invoke the module inplex_google.py in the following way:

python inplex_google.py --user username@gmail.com --pw password

Where you fill in your correct username and password credentials.  If all of that works, the module will log into your Google Contacts, and begin retrieving the whole lot (I have about a thousand, you could have many more), creating entries in the Plex for each one that has a proper name attached to an email address.  In the interests of clarity, it will not add a contact to the Plex that has an email address without a corresponding proper name.  When the module is finished running, the file db/plex.db should contain a basic social graph of your Google Contacts.

To add your Twitter social graph (the people you follow on Twitter) to this, use the module inplex_twitter.py, invoked as follows:

python inplex_twitter.py

If you do not have OAuth credentials, the tool will take you through OAuth authorization.  Once you have authorized access to your Twitter account, the module will retrieve all of your Twitter ‘friends’ – that is, the contacts whom you follow, not the ones who follow you – and add them all to the Plex by proper name and Twitter screen name.  Where there is a proper name that matches an entry already in the Plex, this contact is added as a ‘connection’ to the Plex.

Now, if you want to see what you’ve got inside your Plex, you can run the export module plex2vcard.py, which exports the Plex as a series of Plexus-style ‘vcards’.  (These vcards are actually JSON-serialized objects, not in standard vCard format, but containing the same information.)  You might want to export the output to a file, invoking the module like this:

python plex2vcard.py > plex.vcards

This will create an output file, plex.vcards, which has the exported content of all of the entries in your social graph.

Conversely, if you want to take a vcard file and import it to the Plex – either creating a Plex from scratch, or adding new vcards to an existing plex, you would use the module vcard2plex.py.  If we wanted to import our exported vcards into a Plex (perhaps restoring after trashing our database), we could do it as follows:

cat plex.vcards | python vcard2plex.py

You can then run plex2vcard.py to check to see if all of the vcards have been added to the Plex.

It’s always been my primary goal to have Plexus running on the mobile handset.  The modules that are up and running will currently work under Android using Google’s Scripting Languages for Android (sl4a) application.  You’ll need to install that first, then install the Python interpreter.  Next, copy the entire Plexus source code tree to the directory /sdcard/sl4a/scripts/v2 on your handset.  Navigate to that directory in sl4a, and you should be able to run the applications from your phone!  (Or tablet, if you have an Android tablet.)

This is one of the great advantages of coding Plexus in Python – it’s a very portable language.

Have fun!

sending

front end / api creates rfc2822 message

|

|

plexus_smtp - the message router

|\

| \

|___plxaddr - decodes headers in the rfc2822 message
                     determining the type of message and the destination

|\

| \

|	nq - queues the message for delivery ( stored in db )

|\

| \

|___plex - looks up the destination and decides which sharer to use
                   and the appropriate handle

|\

| creates rfc2822 message

|

|

[service]_sharer - receives rfc2822 message .
                     handles the delivery of the message to the specified service

receiving

[service]_listener - retrieves messages from the specified service .
                       these might be broadcast or direct messages .
                       creates an rfc2822 message with a json body and delivers to...

|

|

plexus_smtp - the message router

|\

| \

|___plxaddr - decodes headers in the rfc2822 message
              determining the type of message and the destination

|\

| \

|___plex - looks up the message sender and origin
              and decodes it into a contact

|\

| \

|	dq - queues the message for receipt ( stored in db )

|\

| creates rfc2822 message

|

|

front end / api - receives rfc2822 message

Credit: Tomás Rotger

A lot of you are coming to visit this site for the first time because of “Smoke Signals“, my linux.conf.au keynote address.  I’ve been so busy getting ready for that talk – and puzzling through v2 of Plexus – that I haven’t done any updates to this site.  Now, however, there are a few changes.  The code repository points to the new github repo for Plexus v2.  There is much more documentation to come – much – as I present the details of the RFC2822 protocol abstraction layer for Plexus.

That’s all for now.

We’re now seeing the emergence of other tools that begin to look a bit like Plexus: Seesmic Desktop 2 has a plugin architecture that allows you to aggregate many different social services.  They ain’t doin it right (the services are still segregated) but it’s a start.  Also, we can expect to see the very first code drop from Diaspora* sometime later today.  I’ll be very excited to get that up and running, to see what can be made of it, and how Plexus can connect with it.

Thanks for your patience.  More as it develops.

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.

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?