next »

[inp o҉rtb]

This project started last week as an experiment of sorts (actually, I had the idea a while ago, but I actually got some work done last week), and today I ended up with a very simple web messaging application. It's like e-mail in that you could have users on multiple domains communicate with each other, and it's like PM in that both sender and recipient are authenticated. And because both parties are authenticated, the sender has to take responsibility for his/her messages (and think twice before sending spam).

So the whole project was to work out a simple scheme in which users can authenticate each other across domains... and a Web-based front-end that lets us actually use the system. I'm thinking about adding public-key cryptography later, but now, we have

(beware, the whole script is downloaded all at once as one page. that's 200kb right there.)

Is anyone willing to help test this system? I'm ready to dish out private testing invitations

[islesv]

Count me in, I'm interested in this thing.

[inp o҉rtb]

Thanks, man; I've PM'd you an invitation link
You might find the step-by-step tutorial helpful.

Hm, I'm going to write up a simple PHP API, so people could do email-free-sendmail-free-fsockopen-free mailing.

[Sinister]

So you can only communicate with those who signed up?
Or can you e-mail ("PM") anyone?   

[inp o҉rtb]

As of now, yes, because MailFeed is currently the only server supporting the protocol. However, if more servers are set up that support the protocol, users on one server could contact users on a different server.

PM is able to authenticate all users because all users are on the same server. Email cannot, because it's a distributed system. MailFeed uses some ghetto handshake procedure to authenticate across servers while maintaining privacy and security.

Speaking of PM... it would be interesting if there were a SMF mod replacing the standard PM with this thinger. Then users from one forum would be able to "PM" users of another forum...

[Timothy Jacobs]

Sign me up for a yes!

[inp o҉rtb]

Thanks the your interest! I'll send you a PM now.

### EDIT ###
I just got rid of Zend JSON for FastJSON because FastJSON is less than 1/3 the size. Instead of XHTML, I decided to use Markdown for formatting. IMO, it's pretty simple to use and makes for a very lightweight composition environment compared to WYSIWYG.

[Huw]

Send me an inv please.

[inp o҉rtb]

Done

I realized that the interface was wayyyy to complicated. Who writes a message and selects recipients on different screens? Therefore... I've merged the Route tab into the Compose tab. And I've merged the Inbox tab into the Read tab.

### EDIT ###

You can now edit and delete your compositions

[cms07]

I would like to, but I'm busy

[inp o҉rtb]

That's alright.

I've introduced some minor user interface improvements. You can now quote inbox messages directly into your composition. I've switched from FastJSON to the PEAR JSON package, because FastJSON is somewhat crippled. The remote call interface should be stable now.

There is now a simple (and incomplete) PHP client class. I've used it to implement a simple contact form.
download: http://www.inportb.com/mailfeed/htmp.api.zip

[antimatter15]

can someone invite me?

Anyways, how does it work?

and just a random idea for your zipstream.php, is implementing JSMin PHP http://code.google.com/p/jsmin-php/ and maybe an expires header. I'm still really impressed on how you got an "A" for yslow...

...and how your code can be so much nicer than mine

[inp o҉rtb]

Absolutely. You now have an invitation

JSMin does sound like a good idea. I was actually considering that, but I find compressed code rather difficult to debug. So... I'm holding off on it for now. Thanks for the suggestion!

[antimatter15]

Absolutely. You now have an invitation

JSMin does sound like a good idea. I was actually considering that, but I find compressed code rather difficult to debug. So... I'm holding off on it for now. Thanks for the suggestion!

since you're index file is a php file, you could have it return two different modes. maybe a URL parameter like inportb.com/mailfeed/?debug=true to skip compressing. and maybe caching the gzipped things somewhere could inprove speed...

i don't like how you can't press "enter" to submit the forms though, and some user interface components could be better hidden, but then again, this probably isn't mean for average user usage.... yet.

it has a really innovative interface.

maybe some history/revision features would be nice, but it already pwns traditional email. i'd love to see more of this. themes would be awesome (maybe you could make a script that changes the hex values in CSS....)

I know this is supposed to have a simple user interface, but what exactly does it do?

I think you should have the server return more cross-domain friendly things like scripts that can be included (though that would kill security, unless you encode it somehow with your session keys or something) that way you could build your own "better" (to that person's opinion) system and only need to copy that file. or are you trying to make it more/less centralized?

Any spam protection? and you used to have that "hitme with spam" email link... do you have a log of that, it might be useful for when i get my AI spam filter working

[inp o҉rtb]

Hm. Debug mode -- that's brilliant. Caching would be a nice idea as well. If the cache is still valid, it can just send an HTTP redirect to the cached file instead of regenerating all the code. I'll be integrating JSMin tonight

I have also found it a bit annoying that you cannot press enter to submit the forms... because they're not real forms. I'll look into attaching some keyboard event handlers to these fields, to allow for enter-submission.

Hm... by history/revision, do you mean version control? I'm not sure at the moment how to implement that... but I'll think more about that sometime. At the moment, you can edit your messages, and recipients would see the revised messages. Themes don't seem too difficult to manage using PHP-generated CSS.

Okay, it's simpler than the previous revisions, but I don't think it's simpler than email... yet
It's supposed to transport your messages, that's all. But extra features (which I am working on) would be nice.

So... to be implemented:
- GZip+JSMin+caching in zipstream.php
- keyboard event handlers in forms
- color themes
- version control

Thanks for your comments!I'm actually trying to make it as decentralized as email. Also, people can use their own clients, as they become available. After all, it's just a protocol, and I'm building the protocol _and_ the implementation at the same time.

There is no spam protection beyond the fact that senders can be identified. I'm still getting a lot of spam in that other inbox. Here is the thread: http://www.110mb.com/forum/empty-t21665.0.html

[antimatter15]

Another idea (oh no! not another ) is to improve multitasking. maybe extending, on the multitasking idea, is to (optionally) have this scroller on a side (top,bottom,left,right, idk) that streams summeries/titles of unread emails

*OFFTOPIC*

Thanks for your comments!I'm actually trying to make it as decentralized as email. Also, people can use their own clients, as they become available. After all, it's just a protocol, and I'm building the protocol _and_ the implementation at the same time.

There is no spam protection beyond the fact that senders can be identified. I'm still getting a lot of spam in that other inbox. Here is the thread: http://www.110mb.com/forum/empty-t21665.0.html

That's been in operation for like 3 months and it gets less spam than my spam filter applied to my site catches in 1 week!

http://jyio.inb.ath.cx/hitme/ vs. antimatter15.110mb.com/phpfusion/spamlog.htm

and my spam filter sorta backfired. it's filled with so much questionable content (read: no images) that it actuallly shows up for alot of disturbing google queries (i blocked it via robots.txt yesterday though) i actually got some traffic from that questionable page.

[inp o҉rtb]

haha, spam control's always been a pretty sticky topic.

so... i implemented some keystroke event handlers. you can now press enter to submit your registration, login, message request, and recipient addition. the cool part is that when you're submitting recipients, the input is returned to the end of the field, so you can enter multiple recipients without touching your mouse.

[antimatter15]

is there any sort of "has recipient read message" button yet?

[fernbap]

Nice idea! Count me in

[inp o҉rtb]

Sure -- an invitation is heading your way (via PM)

is there any sort of "has recipient read message"button yet?

No, and there may not be anytime soon, I suspect. But there will be a "how many times has this message been read" indicator. The reason is that the sender is operating a mini message server of sorts, and can implement a hit counter pretty easily. To have per-recipient resolution, one would have to put a different password on each recipient notification... and this just makes everything pretty difficult to manage. Another way to implement this is to have the recipient authenticate itself when it requests a message. However, this means that the recipient would have to be a server too, and cannot be a desktop-based client.

If you want to track a single recipient, then I'm afraid you'd have to write a separate post for each recipient.