IMAPSN - using IMAP for social networking

[Jason]

Hi, I've been shopping around this idea and would like to get feedback
from anyone interested:

http://imapsn.github.com/

In short it's IMAP + SMTP + actvity streams schema + some email
message types = facebook alternative.

[Darren Bounds]

This sounds fun. Ill definitely take a look.

A few months ago I had built IMAPv4r1 and SMTP interfaces to Cliqset that will never see the light of day. The idea was to organize and consume activity streams via IMAP and proxy Salmon via SMTP.

-
Darren Bounds via mobile device

--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.

[martin svensson]

I also find this interesting. It is a smart way of building a decentralized social network. I know that researchers at Stanford looking at similar ideas.

Martin

[Will Norris]

certainly an interesting idea, especially given all that you get for free with using IMAP/SMTP.  One practical consideration to keep in mind, a lot of the existing protocols have been very deliberate about building on top of HTTP.  Not because HTTP is necessarily the best solution for the task (sometimes it is, sometimes not), but because it is ubiquitous and well understood... more-so than XMPP, SMTP, etc.  You can use a $5/month web host to experiment with an HTTP-based protocol.  Not that this should necessarily be the target market, but it's an important market (look at the attention diaspora has gotten).

Additionally, even among the small to medium sized companies that would be the more "serious" players in this market, you'll find system administrators that are more comfortable with HTTP.  Any sysadmin worth their weight can scale HTTP.  I would not necessarily expect them to have equivalent expertise with XMPP, IMAP, or SMTP.  (can you do edge caching with those protocols?  Does it even make sense to?  I actually don't know)

this is certainly not meant to discourage what you're doing... it actually looks pretty interesting.  I just wanted to provide some perspective on why some things have been designed the way they are.

-will

[Michael Sullivan]

very cool.

i was tinkering with similar stuff in 2009 with a project called nudges.

SMTP + RSS + XSLT for micro-messaging.

Send an email with just a subject and optionally attachment.

That message gets added as a new RSS Item (w/enclosure if attached file).

That RSS feed is transformed with XSLT and CSS to create a presentable web page of the stream.  

I've taken the project down as I repurposed the domain but I recently referenced this in a blog post here:

http://vocal.ly/pr7

I'll be following the progress of IMAPSN.

Sull

[Nigel Hamilton]

NNTP could even make a comeback!? ;-)

[Jason]

On Sep 23, 2:31 pm, Will Norris <w...@willnorris.com> wrote:

> On Tue, Sep 21, 2010 at 2:32 PM, Jason <jasonka...@gmail.com> wrote:
> > Hi, I've been shopping around this idea and would like to get feedback
> > from anyone interested:
>
> >http://imapsn.github.com/
>
> > In short it's IMAP + SMTP + actvity streams schema + some email
> > message types = facebook alternative.
>
> certainly an interesting idea, especially given all that you get for free
> with using IMAP/SMTP.  One practical consideration to keep in mind, a lot of
> the existing protocols have been very deliberate about building on top of
> HTTP.  Not because HTTP is necessarily the best solution for the task
> (sometimes it is, sometimes not), but because it is ubiquitous and well
> understood... more-so than XMPP, SMTP, etc.  You can use a $5/month web host
> to experiment with an HTTP-based protocol.  Not that this should necessarily
> be the target market, but it's an important market (look at the attention
> diaspora has gotten).
>
> Additionally, even among the small to medium sized companies that would be
> the more "serious" players in this market, you'll find system administrators
> that are more comfortable with HTTP.  Any sysadmin worth their weight can
> scale HTTP.  I would not necessarily expect them to have equivalent
> expertise with XMPP, IMAP, or SMTP.  (can you do edge caching with those
> protocols?  Does it even make sense to?  I actually don't know)

You make a good point here. I've seen a zimbra/imap migration go
bad initially because sysadmins didn't plan for load very well.

I'm intending that content like images and videos will come from
HTTP services. The IMAPSN message contents are limited to
application/json attachments. Many messages will be sent but
never read, so large files should be kept out. I don't really
have a good story yet of how an IMAPSN client handles images from
end to end. I'm imagining one would share a link to a site like
picasaweb or flickr, and the client would fetch the image or a
thumbnail. Access control will have to rely on an unpublished
url or on the service's access mechanism (and given that, maybe a
thumbnail should be allowed as an attachment). For uploads,
clients will have to support plug-ins for the various services.

> this is certainly not meant to discourage what you're doing... it actually
> looks pretty interesting.  I just wanted to provide some perspective on why
> some things have been designed the way they are.

Thanks!
-Jason

> -will

[Mike Macgirvin]

On Sep 25, 9:28 am, Jason <jasonka...@gmail.com> wrote:


> I'm intending that content like images and videos will come from
> HTTP services.  The IMAPSN message contents are limited to
> application/json attachments.

>  I don't really
> have a good story yet of how an IMAPSN client handles images from
> end to end.  

First of all you can count me in. IMAP was in fact my first choice for
a social platform - as it solves a lot of authentication/identity and
delivery problems that federated web projects are still struggling
with; but have been off and on pessimistic over the future of all the
email protocols I worked so hard on for decades.

If you provide the ability to link to HTML attachments in the messages
(and I think the pressure to do so will be overwhelming due to the
amount of content that's available over HTTP), you can either attach
of just provide related links. It's a bit selfish to broadcast high-
bandwidth content by default - as some of us live in countries where
our network traffic is metered.

Also be aware that IMAP can share other mailboxes besides those in the
user's default space, and a mailbox can be anything you can map to
IMAP's structures in any abstract way. We used to use this to open
USENET groups and even arbitrary files (such as images) in our email
clients. Consider the possibility of using a "virtual" shared mailbox
with ACL's somewhere on the net as an image source or repository. It's
got rock-solid authentication (because it is session oriented, as
opposed to HTTP where cookies can leak). You can also access it with a
URL. In fact it could be a bridge between IMAP and a web page.