experiment report: inbox functionality

[Michiel B. de Jong]

i did this experiment researching what i call "inbox functionality", so
putting a sort of inbox on your personal server, which can then be
queried by unhosted web apps. the main conclusion is that this is not
super useful. :)

report here:
https://github.com/unhosted/u36/wiki/Experiment-report:-Inbox-Functionality

comments/reactions/discussion very welcome!


Cheers,
Michiel

[François Kooman]

On 11/25/2013 06:58 PM, Michiel B. de Jong wrote:

> There is a practice of running an "irc bot", which occupies your
> place in an irc channel while you are away, but that in itself is not
> strong enough a use case to merit a sequel to the Inbox experiment at
> this point.

I think this is the only use case and that it is worth the effort :-)
But maybe there are IRC bouncer/bots that can stay online for you and
allow you to retrieve messages from the past as well from a Sockethub
module?

For XMPP it offers an additional benefit as with OTR sessions you both
need to be online to exchanges messages as a PFS TLS session is started
between the two clients. If this is handled by Sockethub/Inbox/Outbox
that would help to get offline messaging working with OTR[*]. Also, not
all implementations work reliable with offline messaging, but I guess it
is not a reason to build this just to work around Faceboogle screw-ups :)

Also, when working on a mobile device in the train using wireless
networks the connection drops quite often. To be able to make sure no
messages are lost would be helpful. Also not dropping offline all the
time for your chat partner may be nice where they have no idea their
message was actually received (especially in IRC use case).

So the two use cases:

1. IRC for receiving groupchat messages and direct messages when you are
not there (browser not running)
2. XMPP for receiving (optionally OTR encrypted) messages when you are away

Cheers,
Fran�ois

[*] One could argue that this is bad idea as it would encourage users to
not terminate OTR sessions at their actual 'terminal' and on some server
they don't necessarily fully trust. So this is only acceptable if the
Sockethub/Inbox runs on their own laptop or "FreedomBox" at home (like
Mailpile)

[Bryce Lynch]

On Tue, Nov 26, 2013 at 12:14 AM, François Kooman <fko...@tuxed.net> wrote:

> But maybe there are IRC bouncer/bots that can stay online for you and
> allow you to retrieve messages from the past as well from a Sockethub
> module?

Cozy (http://cozy.io/) has such functionality. You might want to see
how they implemented it.

> 1. IRC for receiving groupchat messages and direct messages when you are
> not there (browser not running)

Setting up a private, miniature IRC server that has one or two bots
acting in your service that read messages into it (which you can pick
up later) is doable.

--
The Doctor [412/724/301/703] [ZS]
https://drwho.virtadpt.net/
"I am everywhere."

[Nick Jennings]

Hi everyone, I just wanted to clarify something that I don't think is clear in Michiels post.

Sockethub has always had plans for providing functions for queuing messages from chat services while offline. As well as providing an HTTP point for accepting POSTs of messages as ActivityStreams. These two things are what Michiel calls "inbox functionality" but I think that can be misleading to use as a bullet-point feature, as the implementations for the two things are quite different. I use the terms "offline message queuing" for the offline chat functionality, and "incoming requests" for other users/apps contacting you via. your sockethub instance (HTTP POST of an ActivityStream).

As I said this has been part of my vision from the beginning, and it's always just been a matter of man-hours, and getting other pieces implemented and stable before venturing into more advanced areas. I've made this clear to Michiel before...

- offline message queuing is a work in progress and many of the pieces are already there (explained further down)

- incoming requests is definitely something I want to add but no work has been done there yet, as there are lots of things which need to be created (apps, for one) before that functionality can be of any use to anyone.

On 11/25/2013 06:58 PM, Michiel B. de Jong wrote:
>

> Given the big overlap in source code needed by an inbox server like
> Welten and a messaging server like sockethub, the code was first
> designed as a next version of sockethub, including all the existing
> sockethub platforms, plus remoteStorage.
>

This was never the case. Welten was never going to be a next version of Sockethub, nor was any of this discussed as part of the Sockethub project. Functionality and code wise, it could not be considered a next version either. It was not multi-user, not compatible, and was missing a lot of existing functionality.

Sockethub has a much different approach to the issue of inbox functionality, taking into account a scalable, mutli-user system, and avoids crippling the software stack by forcing credentials to be hard-coded in order to achieve some functionality.

I think it's important to make this clarification because by saying it was intended to be the next version of Sockethub, you are implying that A. You and I were in agreement about welten, and B. That the current Sockethub is somehow insufficient and needed a replacement, and C. That the current Sockethub cannot provide inbox functionality, which it certainly can.

## Incoming Requests

The goals of Sockethub are to provide a generic API to messaging from unhosted web apps, that includes posting to someone elses instance. Consider for example, a webfinger record that has a sockethub entry along with it's remotestorage one:

    ... 
    {
      "href": "https://storage.5apps.com/silverbucket",
      "rel": "remotestorage",
      "type": "https://www.w3.org/community/rww/wiki/read-write-web-00#simple",
      "properties": {
        "http://tools.ietf.org/html/rfc6749#section-4.2": "https://5apps.com/rs/oauth/silverbucket"
      }
    },

    {
      "href": "https://sockethub.5apps.com/",
      "rel": "sockethub",
      "type": "http://sockethub.org/rel/sockethub",
      "properties": {
        "http://sockethub.org/rel/useraddress": "ni...@silverbucket.net"

      }
    }
    ...

Now, consider another users wants to get a hold of you. They have your sockethub endpoint, and the user address you register as when you connect to it.

With that information they could make an HTTP POST to sockethub, something like:

HTTP POST https://sockethub.5apps.com/

{

  "actor": {

    "address": "mic...@michielbdejong.com",

    "name": "Michiel B. de Jong"
  },

  "target": [
    {

      "address": "ni...@silverbucket.net"
    }
  ],

  "platform": "webrtc",

  "verb": "invite",

  "object": {

    // .... webrtc connect information ...
  }

}

This is all hypothetical for now, but the idea is that if I'm online, with a WebRTC enabled app, I'd get your invitation for a WebRTC chat.

## Offline Messaging Queue

Now, you also use the term "inbox functionality" to cover storing incoming messages from a chat service like IRC or XMPP, but actually it will be a totally different approach within Sockethub.

As some of you know. Sockethub currently supports XMPP and IRC, and the application Dogtalk is currently in functional prototype phase, however I plan to improve it's quality as I begin working more on the following "offline message queuing" functionality.

Each platform currently has access to a ClientManager object, which acts as sort of a connection pool/manager. It holds the connection objects for you, registers all the listeners. I want to keep this brief, but basically the listeners will handle incoming messages and if there is no current application using the connection object, it will store the message to a storage target. This storage target is abstracted, but if remoteStorage has been configured by the app who initialized the connection, the message can be stored there. The ClientManager is implemented, and writing to remoteStorage is implemented, but the logic and edge cases surrounding how to behave, watching for connection/handler leaks, and what to do when someone never comes back to reclaim their object, are still not fully worked out and implemented.

I hope this gives people a better idea of the goals for Sockethub! Let me know if you have any questions.

Cheers
Nick

Current sockethub apps:

*  Dogfeed - https://dogfeed.5apps.com  (stable)

*  Dogtalk -  https://dogtalk.5apps.com (alpha - prototype)

--

--- You received this message because you are subscribed to the Google Groups "Unhosted Web Apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unhosted+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Michiel B. de Jong]

On 02-Dec-13 1:26, Nick Jennings wrote:
>
> On 11/25/2013 06:58 PM, Michiel B. de Jong wrote:
> >
> > Given the big overlap in source code needed by an inbox server like
> > Welten and a messaging server like sockethub, the code was first
> > designed as a next version of sockethub, including all the existing
> > sockethub platforms, plus remoteStorage.
> >
>
> This was never the case. Welten was never going to be a next version
> of Sockethub, nor was any of this discussed as part of the Sockethub
> project. Functionality and code wise, it could not be considered a
> next version either. It was not multi-user, not compatible, and was
> missing a lot of existing functionality.
>
> Sockethub has a much different approach to the issue of inbox
> functionality, taking into account a scalable, mutli-user system, and
> avoids crippling the software stack by forcing credentials to be
> hard-coded in order to achieve some functionality.
>
> I think it's important to make this clarification because by saying it
> was intended to be the next version of Sockethub, you are implying
> that A. You and I were in agreement about welten, and B. That the
> current Sockethub is somehow insufficient and needed a replacement,
> and C. That the current Sockethub cannot provide inbox functionality,
> which it certainly can.

right, i see how my sloppy formulation there was confusing, sorry.
indeed, none of these things are the case. this was just an exploratory
experiment, hopefully the conclusions can help to get it right when the
time is there to implement it in sockethub proper.

thanks for posting this clarification! that really helps to put things
in context.


cheers,
Michiel.