Stream Entries can have multiple Streams?

[peterk]

Hey everyone,

Maybe I'm approaching this the wrong way..but anyhow..

Basically I'm trying to provide functionality where a user can send a
private direct message to another user or users who are subscribed to
them.

In trying to do this, I was thinking that each user could have
multiple 'private' streams for each of its contacts wherein private
messages to those contacts could be published.

But if, say, a message is intended for multiple recipients, then the
Stream_Entry would need to refer to multiple such streams. As is,
currently, a Stream_Entry points to one Stream.

I've dug around a bit in _process_new_entry_with_progress to see how
easily I could modify things to process Stream_Entry objects that
have, say, a list of streams rather than just one. It seems that the
_who_cares functions can find subscribers based on more streams than
just the single stream the entry refers to - e.g. it seems to add
subscribers to an entry's comments as well, held in a different stream
- so it seems like you could 'just' add a different property to a
Stream_Entry that holds multiple streams in addition to the single
stream property, and make sure who_cares finds subscribers based on
those streams too.

The problem is that the _add_inbox functions need to take a stream
reference..and in a case like this it seems hard to know which stream
reference to pass. I also wouldn't want such messages published to a
user's presence stream since they wouldn't be intended to be public,
so there'd be the question of which stream to use as its 'primary'
stream property.

I don't know if I'm over thinking this or taking an obscure route to
this functionality or not..if anyone has more simple ideas I'd love to
know. As far as I can tell there isn't functionality there to let
users send private messages to another user or arbitrary group of
users..?

Thanks in advance for any advice.. :)

[Andy Smith]

On Wed, Apr 15, 2009 at 9:35 AM, peterk <peter...@gmail.com> wrote:

Hey everyone,

Maybe I'm approaching this the wrong way..but anyhow..

Basically I'm trying to provide functionality where a user can send a
private direct message to another user or users who are subscribed to
them.

I've thought about this functionality a bit, vague approach:

Give every user an additional stream, read privacy private, stream/ni...@domain.com/direct

When sending a direct message, you are going to make a new StreamEntry, perhaps with the recipient nicks in the extra field so that we can validate that they are allowed to see it, and then make an InboxEntry with something like inbox/reci...@domain.com/direct (and probably add it to their overview also)

 

In trying to do this, I was thinking that each user could have
multiple 'private' streams for each of its contacts wherein private
messages to those contacts could be published.

But if, say, a message is intended for multiple recipients, then the
Stream_Entry would need to refer to multiple such streams. As is,
currently, a Stream_Entry points to one Stream.

I'd think more in terms of InboxEntry targets, there is one Stream where something is located, but the visibility depends on the InboxEntry

Hope that helps :)

--andy
 

[peterk]

Hey Andy,

Thanks so much for your reply. I've been doing a bit of coding along
these lines, but I've run into a bit of a snag.

For starters I'm just trying to get 1:1 direct messaging working. I'm
giving each user a private direct stream, and am indexing entries in
these streams in inboxes according to a recipient stored in the extra
field of the StreamEntry.

Here's the snag though: although I index the entry in the recipient's
overview inbox, messages sent like this don't appear in the
recipient's overview. Doing some digging, I think the system is
preventing it from showing up because the sender's direct stream
permissions (i.e. private) dictate that this user shouldn't be able to
see the streamentry. entry_get_safe seems to enforce this.

I've been thinking I could get around this by perhaps making a special
case of this in the entry_get_safe function based on any recipient
listed in the StreamEntry, but I'm not totally familiar with the
permissions system in jaikuengine, and I was wondering if there might
be a more elegant or appropriate solution..?

Thanks again for any input, your advice has been great :)



On Apr 15, 7:34 pm, Andy Smith <andys...@gmail.com> wrote:

> On Wed, Apr 15, 2009 at 9:35 AM, peterk <peter.ke...@gmail.com> wrote:
>
> > Hey everyone,
>
> > Maybe I'm approaching this the wrong way..but anyhow..
>
> > Basically I'm trying to provide functionality where a user can send a
> > private direct message to another user or users who are subscribed to
> > them.
>
> I've thought about this functionality a bit, vague approach:
>
> Give every user an additional stream, read privacy private, stream/

> n...@domain.com/direct

>
> When sending a direct message, you are going to make a new StreamEntry,
> perhaps with the recipient nicks in the extra field so that we can validate
> that they are allowed to see it, and then make an InboxEntry with something

> like inbox/recipi...@domain.com/direct (and probably add it to their

[Andy Smith]

On Thu, Apr 16, 2009 at 8:52 AM, peterk <peter...@gmail.com> wrote:

Hey Andy,

Thanks so much for your reply. I've been doing a bit of coding along
these lines, but I've run into a bit of a snag.

For starters I'm just trying to get 1:1 direct messaging working. I'm
giving each user a private direct stream, and am indexing entries in
these streams in inboxes according to a recipient stored in the extra
field of the StreamEntry.

Here's the snag though: although I index the entry in the recipient's
overview inbox, messages sent like this don't appear in the
recipient's overview. Doing some digging, I think the system is
preventing it from showing up because the sender's direct stream
permissions (i.e. private) dictate that this user shouldn't be able to
see the streamentry. entry_get_safe seems to enforce this.

I've been thinking I could get around this by perhaps making a special
case of this in the entry_get_safe function based on any recipient
listed in the StreamEntry, but I'm not totally familiar with the
permissions system in jaikuengine, and I was wondering if there might
be a more elegant or appropriate solution..?

Aye, there is definitely a bit of a snag there. Ideally simply changing actor_can_view_entry() would be enough but most likely the permission call to fetch the stream info will fail for that. It would be nice to adjust the way the stream is handled to be slightly more fault tolerant, for example imagine what would happen if stream is None, problems arise there too however because we handle deleted streams (and hence deleted entries in that stream) by making that check... so some refactoring of how deleted vs permission vs not found is handled might be necessary.

The alternative is to make the stream public (probably give it a "type" of direct as well) and have actor_can_view_entry() make an additional check of the extra "recipients." This feels slightly less secure to me as it opens a big whole and then tries to close it rather than making a little hole, but is probably much more straightforward to do.

Are you planning on submitting these changes as a patch?

--andy

 

[peterk]

Hey Andy,

I gave your first approach a go i.e. trying to alter
actor_can_view_entry.

That's simple enough, to make an exception there if a message is
direct and the api_user is the recipient. But there are side effects
in a couple of other places as you suggested. Namely, as far as I can
see, in api:entry_get where stream_get() falls over if the permissions
aren't there. So you have to make an exception there to not call
stream_get() if the message is direct and the api_user is the
recipient.

Further, in display:prep_entry, the entry's stream is appended to the
entry... you'll get a key error when it tries to find the entry's
(direct) stream in the list of streams passed (the list you have
permission to view, which obviously doesn't include others' direct
streams). So I've had to add another exception there where if the
message is direct and api user is the recipient, it'll get the Stream
directly and assign that to the entry.

I *think* they're the only places that need changing? At first blush
it seems to be working now, direct messages show up in the overviews
of the recipients and the senders, but nowhere else as far as I can
tell. I haven't set up views for direct message inboxes yet, and I
should probably create inbox entries for a recipient's private inbox
also.

Are the above workarounds sort of 'acceptable' from a security POV? Am
I opening up holes here, or is it OK as long as I only make exceptions
where an entry is 'direct' and the api user is the recipient?

Are there other places where I'd need to make changes too that aren't
as obvious? I haven't really done any major testing here, just
eyeballing it so to speak..

If I got this working with multiple recipients, and I tidied up some
things that are pretty ugly right now, I'd be happy to submit a patch
with the changes..i've never submitted a patch to a open source
project before, but i assume it's a fairly straight forward process..

Thanks again for your time!



On Apr 16, 9:28 pm, Andy Smith <andys...@gmail.com> wrote: