#21 [RFC] Expansion of XMPP plugin's functionality

Open
opened 2 months ago by diogo · 0 comments
<rozzin>    I have been thinking on the possibility of making some sort of actual XMPP *transport* that could do
            JID-mapping..., but so far it seems like the conceptual models of XMPP vs. GNU social are probably just too
            different.
<lnxw37>    Probably less than it appears. In past times, I did have someone who misconfigured their XMPP
            bridge whose posts came directly to my IM account. IMO, such a system is going to be the only way we get
            true federated DMs. The current scope-limited posts that other fediverse software calls DMs fail in that
            regard.
<rozzin>    lnxw37: I'm failing to follow...
<rozzin>    lnxw37: I'm afraid I don't understand any of the things that you just said :(
<lnxw37>    rozzin: (1) I had an XMPP enabled instance and someone else had an XMPP enabled instance.
            Whenever a user of that instance mentioned a user of my instance, if my user had connected an XMPP account,
            the mention went straight there without appearing on the timeline.
<lnxw37>    (2) Direct messages / private messages are something different than just limiting the scope
            (recipients list) of a regular post, as most AP implementations do. Attaching an XMPP server is a way to
            have real DMs.
            And with OTR or OMEMO, they can become actual _private_ messages.
<lnxw37>    The dentmaster (admin) of the other instance said he had misconfigured something. Once he fixed
            it, the occurence at (1) went away.
<rozzin>    lnxw37: OK, I'm mostly struggling to understand how (1) could have happened.
<rozzin>    lnxw37: also, when you say "the mention went straight there without appearing on the
            timeline", you mean that it went straight through from
            his social server > OStatus -> your social server -> out thru the XMPP bot?
<rozzin>    lnxw37: ... without appearing in which timeline(s)?
<lnxw37>    rozzin: I believe it went:
            Their user —> their server —> their instance's XMPP server —> our instance's XMPP server —> our user's XMPP
            account.
<rozzin>    lnxw37: meaning that you got XMPP messages from *his bot* instead of your own?
<rozzin>    lnxw37: I should clarify that I haven't _used_ the GNU social XMPP plugin; IIRC I saw some
            screenshots from other people using it ages ago, and I've (somewhat) more recently skimmed the code...; from
            what I've seen of how the plugin works, that "their instance's XMPP server —> our instance's XMPP server"
            leg doesn't seem possible.
<lnxw37>    No, I think it went from their bot to my bot to me, without OStatus or my instance being
            involved. It was years ago, so I cannot recall the details, but I always remembered that posts could travel
            through the XMPP network as well as the OStatus network.
<rozzin>    I guess we could try to reproduce the misconfiguration :)
<rozzin>    Hmm....
<rozzin>    There is "public feed" option to "You can send *all* messages from your social networking site to a
            third-party service using XMPP" that I see;
<rozzin>    and if the receiving bot is parsing the @-references out of the messages that it receives (and IIRC
            there were a bunch of places where the GNU social code did that even though it sometimes didn't necessarily
            make sense for it to do so...), then maybe that would do it?
<diogo>     lnxw37: that's really interesting...
<diogo>     rozzin: The OStatus plugin has large chunks of code for parsing @-mentions and there are
            ActivityStreams classes that allow you to instantiate AS objects from AS messages
<rozzin>    Yes, that's what I said :)
<diogo>     so, yeah, that is probably doable :)
<diogo>     It was already in the plans to work on that, like you said there seems to be some redundancy
            (but that has to be carefully analysed), and it's important to add core support for AS2
<rozzin>    Anyway, what I was originally talking about as "the models being too different" was XMPP clients as a
            UI, not XMPP S2S as a distribution mechanism.
<rozzin>    There is actually a XEP that was written specifically targetted at enabling XMPP to be a back-end
            distribution mechanism for this sort of content (I don't remember much of the specifics);
<rozzin>    but when I said "the XMPP bot doesn't cut it", I meant as a front-end, i.e. "telling iPhone users to
            just use ChatSecure or Tigase or whatever XMPP client as a way of listening for new notices from GNU social"
            doesn't seem realistic.
<lnxw37>    You're very likely correct.
            As a Windows / Linux / WebOS / Android user, I found the XMPP bot to be an easy way to cut through all the
            things that come with using the WebUI. But I haven't had a working XMPP bot in years, so I cannot even say
            for sure that I'd get a lot of utility from it.
<rozzin>    Hmm. Did Finnie ever release source for x11r5?
<rozzin>    Any recommendations for social chatterbot codebases?
<lnxw37>    I think he said that having multiple X11R5 bots would make the original non-unique. Though we'd already
            heard about offspring “TinCanJr” by then.
<rozzin>    phbbt.
<rozzin> I have been thinking on the possibility of making some sort of actual XMPP *transport* that could do JID-mapping..., but so far it seems like the conceptual models of XMPP vs. GNU social are probably just too different. <lnxw37> Probably less than it appears. In past times, I did have someone who misconfigured their XMPP bridge whose posts came directly to my IM account. IMO, such a system is going to be the only way we get true federated DMs. The current scope-limited posts that other fediverse software calls DMs fail in that regard. <rozzin> lnxw37: I'm failing to follow... <rozzin> lnxw37: I'm afraid I don't understand any of the things that you just said :( <lnxw37> rozzin: (1) I had an XMPP enabled instance and someone else had an XMPP enabled instance. Whenever a user of that instance mentioned a user of my instance, if my user had connected an XMPP account, the mention went straight there without appearing on the timeline. <lnxw37> (2) Direct messages / private messages are something different than just limiting the scope (recipients list) of a regular post, as most AP implementations do. Attaching an XMPP server is a way to have real DMs. And with OTR or OMEMO, they can become actual _private_ messages. <lnxw37> The dentmaster (admin) of the other instance said he had misconfigured something. Once he fixed it, the occurence at (1) went away. <rozzin> lnxw37: OK, I'm mostly struggling to understand how (1) could have happened. <rozzin> lnxw37: also, when you say "the mention went straight there without appearing on the timeline", you mean that it went straight through from his social server > OStatus -> your social server -> out thru the XMPP bot? <rozzin> lnxw37: ... without appearing in which timeline(s)? <lnxw37> rozzin: I believe it went: Their user —> their server —> their instance's XMPP server —> our instance's XMPP server —> our user's XMPP account. <rozzin> lnxw37: meaning that you got XMPP messages from *his bot* instead of your own? <rozzin> lnxw37: I should clarify that I haven't _used_ the GNU social XMPP plugin; IIRC I saw some screenshots from other people using it ages ago, and I've (somewhat) more recently skimmed the code...; from what I've seen of how the plugin works, that "their instance's XMPP server —> our instance's XMPP server" leg doesn't seem possible. <lnxw37> No, I think it went from their bot to my bot to me, without OStatus or my instance being involved. It was years ago, so I cannot recall the details, but I always remembered that posts could travel through the XMPP network as well as the OStatus network. <rozzin> I guess we could try to reproduce the misconfiguration :) <rozzin> Hmm.... <rozzin> There is "public feed" option to "You can send *all* messages from your social networking site to a third-party service using XMPP" that I see; <rozzin> and if the receiving bot is parsing the @-references out of the messages that it receives (and IIRC there were a bunch of places where the GNU social code did that even though it sometimes didn't necessarily make sense for it to do so...), then maybe that would do it? <diogo> lnxw37: that's really interesting... <diogo> rozzin: The OStatus plugin has large chunks of code for parsing @-mentions and there are ActivityStreams classes that allow you to instantiate AS objects from AS messages <rozzin> Yes, that's what I said :) <diogo> so, yeah, that is probably doable :) <diogo> It was already in the plans to work on that, like you said there seems to be some redundancy (but that has to be carefully analysed), and it's important to add core support for AS2 <rozzin> Anyway, what I was originally talking about as "the models being too different" was XMPP clients as a UI, not XMPP S2S as a distribution mechanism. <rozzin> There is actually a XEP that was written specifically targetted at enabling XMPP to be a back-end distribution mechanism for this sort of content (I don't remember much of the specifics); <rozzin> but when I said "the XMPP bot doesn't cut it", I meant as a front-end, i.e. "telling iPhone users to just use ChatSecure or Tigase or whatever XMPP client as a way of listening for new notices from GNU social" doesn't seem realistic. <lnxw37> You're very likely correct. As a Windows / Linux / WebOS / Android user, I found the XMPP bot to be an easy way to cut through all the things that come with using the WebUI. But I haven't had a working XMPP bot in years, so I cannot even say for sure that I'd get a lot of utility from it. <rozzin> Hmm. Did Finnie ever release source for x11r5? <rozzin> Any recommendations for social chatterbot codebases? <lnxw37> I think he said that having multiple X11R5 bots would make the original non-unique. Though we'd already heard about offspring “TinCanJr” by then. <rozzin> phbbt.
Sign in to join this conversation.
No Milestone
No assignee
1 Participants
Loading...
Cancel
Save
There is no content yet.