On Tuesday, February 12, 2013 08:34:42 AM Simon Tennant wrote:
> One solution that might give you some milage: using DISCO to point to a pub
> sub component that is nominated for social activities? (Something like https
> ://buddycloud.org/wiki/XMPP_XEP#buddycloud_Server_Discovery). This will
>
>
I understand that you want to do lookup in PEP. I'd be very wary of
depending on it to build a full scaled social platform.
We tried using PEP to build buddycloud. We created a bunch of nodes for
each and would push out updates based on presence. This kinda worked with
the following caveats::
- it
On 02/12/2013 01:29 AM, Jaussoin Timothée wrote:
> The user's server could track all their subscriptions, but this would be
> prone to errors and would necessitate their server understanding pubsub to
> some extent.
What errors? Unfortunately, with PEP server must understand pubsub
anyway so I don'
:) Your protocol is ok, but I think you should use separate item in a
node for each link you want to share. You may use items id equals to a
jid of a node to share to be able to retract it quickly.
Sorry for my carelessness.
On 02/12/2013 01:29 AM, Jaussoin Timothée wrote:
>>
> Sorry for this mis
Pubsub is different but PEP shares it's subscriptions with roster, so
you may look at your roster as on your "Friend list" and build a
protocol to share your friend list. What's wrong with it?
On 02/11/2013 11:02 PM, Ashley Ward wrote:
> The problem with this list being maintained by the server is
Le 11/02/2013 17:02, Ashley Ward a écrit :
The problem with this list being maintained by the server is that there is
no central point where all of a user's pubsub subscriptions are stored.
The user's server could track all their subscriptions, but this would be
prone to errors and would necessit
The problem with this list being maintained by the server is that there is
no central point where all of a user's pubsub subscriptions are stored.
The user's server could track all their subscriptions, but this would be
prone to errors and would necessitate their server understanding pubsub to
some
On Feb 11, 2013, at 6:25 AM, Stefan Strigler wrote:
> Hi,
>
> Am 08.02.2013 um 23:55 schrieb Matt Miller :
>
>> In working on the patch to address HTTP pipelining, I cascaded into section
>> 16: Multiple Streams.
>>
>> Multiple Streams seems to require support for HTTP pipelining, but feels
Hi,
Am 08.02.2013 um 23:55 schrieb Matt Miller :
> In working on the patch to address HTTP pipelining, I cascaded into section
> 16: Multiple Streams.
>
> Multiple Streams seems to require support for HTTP pipelining, but feels as
> if it runs afoul of even the basic requirements for HTTP pipe
I am trying to show that this list should be maintained by the server.
But probably this thing should not rely on PEP at all, it could be done
as separate "friend sharing" XEP.
The only thing subscription list for a pubsub node can be useful is to
see which users have subscribed to some topic, but
Then perhaps we could just go full circle back to where you started and
have a simple xep which says something along the lines of
-
If an entity wishes to make pubsub subscriptions publicly available then
the entity MAY publish them to a PEP node with the id
'urn:xmpp:pubsub:subscriptions'. The en
Obviously, the most simple way is to make application specific extension
and forget about it... Until the moment another client will implement
it's own version of the same protocol (we should agree that the problem
is widespread enough). Then it will become a hell which can be prevented
earlier tha
On 11/02/2013 11:36, "Sergey Dobrov" wrote:
>This fact will do this protocol even more complicated.
I think this is the exact reason why it should be application specific.
Trying to cover all the bases to make it general purpose would be
extremely complicated. At the moment your home server do
It will be not handy to maintain the list manually through the
application specific protocol. It would be better to have some "Friends
sharing protocol" instead, I think. The other problem here (that doesn't
keep in mind modern social networks) is that user's friends may not want
to be visible in o
On 11/02/2013 10:24, "Sergey Dobrov" wrote:
>Don't you guys think that the fact that PEP has subscribers from a
>user's roster does such feature dangerous?
Yes, I agree. You wouldn't want to make this the general case as there are
serious privacy concerns with automatically sharing this informat
Don't you guys think that the fact that PEP has subscribers from a
user's roster does such feature dangerous? Not all users are ok with
sharing their rosters.
I think that this feature (friends sharing) is completely different and
should be a subject of another XEP.
On 02/11/2013 05:04 PM, Ashley
Le 08/02/2013 08:48, Tim a écrit :
>The idea here is to use PEP to store a list of pubsub nodes and
> allowing a user to notify its contacts when he wants to share some of
> theses.
Quite like the idea of making this information available on a pep node,
but I think you would need to consider diff
17 matches
Mail list logo
