XSF Discussion - 2020-05-04

About old and new mucrooms... There is not forward possibility? :)

That depends on the oldroom, and also on client support (via <gone/>)

Should write something about that, Informational XEP or something. Tombstones and redirects.

tomatoes and redirects

MattJ, Ge0rG: any comments so far? I would like to make progress soon

marc: sorry, I've had limited time the past week or so

Will look into it today if I can

same from me

need to read and understand both proposals first.

XEP-0289 FMUC question, related to section 5.2 ( https://xmpp.org/extensions/xep-0289.html#messages ). The example describes how a joining FMUC node (elsinore) sends a message to the joined FMUC node (rabbithole). Federation is configured to use the master-slave mode (where rabbithole is the master). This sentence makes me wonder if I misunderstand a key part of the XEP: > This example is for master-master mode, so rabbithole does not echo the message back to elsinore and elsinore does not need to wait for receipt of this stanza from rabbithole (...) As I understand the XEP, the federation is initiated by elisnore. This is where the configuration lives. No negotiation of the configuration (specifically, the type of mode that's used) seems to take place. This is also referenced to in section 5.1: > Note that this configuration only needs to be one way (that is: there is no protocol reason why rabbithole needs to know that elsinor will be federating with it in advance) How does rabbithole determine that it needs not echo the message back to elsinore?

MattJ, Ge0rG: 👍

(I've taken my question above to the list) ✏

Does anyone remember what led XEP-0215 to be broadened from "STUN Server Discovery for Jingle" to the generic-but-not-quite "External Service Discovery" it is now? ( check https://xmpp.org/extensions/attic/xep-0215-0.1.html ) Going to look trough some archives prior to https://mail.jabber.org/pipermail/standards/2007-August/thread.html#16602 but there's not much explicit mention of 215 in any subjects)

https://mail.jabber.org/pipermail/standards/2007-August/016266.html

Yeah, that seems to be the thread

What is this Room about?

The XMPP standards

Zash: ahh - direct sending of files from user to user should be default :)

And possible with any size file

wat

you seem to be misunderstanding what "standards" or "xmpp" means in this context

Also I would like to raise to our non-existent Code of Conduct committee some issues I have.

This is about boring text documents that describe how you'd do that. It's up to developers to decide what methods to use when.

pep., write a Procedural XEP about it? :P

Well I thought XMPP could do direct sending of files like in the old days chat applications.

I guess the server decide then on the size of the file.

:/

So if i wanna send a 4 gb file to someone how to do it on XMPP?

DarkiJah: this is possible with a protocol called Jingle.

XEP-0234 iirc

vanitasvitae: great, that is the same thing used for voice and video?

actually a few ways I think? but yes, direct user to user can happen with existing protocols

Kind of

So we just need someone to put it into XMPP clients?

This is already done for files too large to upload to the server afaik

the problem is DarkiJah - JesusIsGodAlmighty.Life , you might not want that, or your contact might not want it, I'm connected to the same account via various clients at the moment, how do *you* know which client *I* want to recieve said file on?

Jingle is used for negotiation of a transport

moparisthebest: lets get back to the old days then sending a file directly fron user to user :)

and explain how to do that if your contact is connected via multiple clients?

in the old days, you were just connected from your PC :P

moparisthebest: you couls accept on the client you want it???

Could

DarkiJah - JesusIsGodAlmighty.Life, what if you went offline before I decided where I wanted to accept it?

moparisthebest: don't make it harder then it is :)

But it is

this is the problem http upload solves

Use https://xmpp.org/extensions/xep-0385.html

Then it gets lost of cause no brainy

you upload it, I can grab it from any of my clients whenever I choose later, even if we aren't online at the same time

Yes but you don't have the option for bigger files.

yes you do?

If you run your own server you can decide that limit

you can set your http upload server to accept *any* size file

Its needing s middle man which is a bottle neck

mine is set to allow 1gb for example

But its better for multi client use cases

also MUC like here

Like, you want to receive the file on two devices? With jingle you have to send it twice

Yeah

I can understand the appeal of jingle file transfer, but http upload is what most people really want to use

But again, modern clients often support both methods

Conversations does at least

Gajim too, right?

I'd assume so

Gajim implements XEP-**** :P

Sound file incoming on the subject

https://share.conversations.im/darkijah/JkSBuFGjMn1vNsgV/RECORDING_20200504_184717741.m4a

Are audio files stored on the mobile by the way?

Like the one I just posted?

This is a question for the developer of your client

Zash: roger

well, that one is stored on your http upload server for a time too, and another example where direct transfer wouldn't work

I'm not going to listen to it regardless :)

DarkiJah: as already said, jingle file transfer is what you describe, and its a thing

moparisthebest: well no point in talking to you further.

So if you want to make use of it, go ahead :)

DarkiJah - JesusIsGodAlmighty.Life, because I'm texting and aren't going to listen to your recordings instead? meh

Roger, see if I can point it out to some of the programmers

You are welcome to do so :)

moparisthebest: why use time on you and the the subject if your not going to listen to/my arguments.

Just dont expect people to immediatelly implement it, as its not exactly trivial to do.

vanitasvitae: you mean it is not easy to do?

I implemented it and it took 3 months

vanitasvitae: 3 month to make?

And since it really only suits an edge case (sending large files), I personally wouldnt implement it again

Yes

Most people are okay with sending smaller files

Sigh

For bigger files there are other methods like uploading the file to a cloud or whatever

I understand your arguments and your opinion, but I also have my own :)

Uploading to a cloud, just like HTTP upload?

:P

s/cloud/some service with a higher limit/g

Nothing about the http upload itself prevents you from hooking that up :)

Sure :)

I think there are even modules that allow upload to eg. Nextcloud, right?

Dunno, I don't see there couldn't be.

DarkiJah - JesusIsGodAlmighty.Life, you misunderstand, I'll *read* your arguments, I'm not *listening* to anything

I tried to explain what you want is 1. already implemented 2. suboptimal/impossible depending on certain things

if you have further questions, go for it

Guus, I don't see any FMUC post yet

Oh hold on is my email broken?

Seems I've been accidentally IPv6-only for a week.

probably a pretty good sign that you hardly noticed :)

https://pbfcomics.com/comics/post-apocalyptic/

> probably a pretty good sign that you hardly noticed :) Not receiving email is a good way to not notice outage.

Receiving high-volume mail but not low-volume mail is even better

Do like thoughts on that fmuc issue

Mostly: is that an omission in the XEP, or did I misunderstand something?