jdev - 2020-01-22

flow , can you provide the link for the official ejabberd muc?

leosbrf, it's well hidden at the end of https://docs.ejabberd.im/get-started/

leosbrf, you can look it up yourself, like any other MUC, at https://search.jabber.network/

> lovetox> em, disco info comes to mind? I usually view disco#info results as "this server supports this" and not as "you are allowed to use this feature"

how you discover that you are allowed or not allowed to use a feature is a good question. Typically you should get an error IQ back as response to an attempt to use a feature that, while being supported by the server, is not allowed for your account. Of course that error IQ should include a reasonable condition and a helpful text explaining that you are not allowed to do this because $reason

Zash / MattJ I've been asked to add a feature like Prosody's HTML log viewer to Openfire. Any obvious things I should take into consideration?

things you learned the hard way, when you implemented it?

flow i think you misunderstood the requirement

> senders should be aware of the recipient will not be able to answer because of that policy.

so not the account itself does need that info

other partys need the capabilities of the other client

which is exactly what disco info is for

and for your own capabilities you just disco info your own bare account jid

which is done all the time, to see if MAM can be used and which version

or httpupload, or whatever

lovetox, right I misunderstood. However, I don't think that this makes my statement wrong.

but you are wrong, disco info to your bare jid does not in any way suggest what a server supports or not

it tells you exactly what your account is able to use or not

Guus: Calendars are complicated. The current one is roughly a MAM query filtered through a template language. I'm kinda happy with that.

if you want to know what a server supports, you have to disco info the service or host

domain.org, or conference.domain.org

or disco items to domain.org

thats how you find out what a server supports

lovetox, that is potentially true, I believe that capabilities are often more fine-grained than the features returned by disco#info, so I am not sure if this is the right mechanism for that. I could be wrong though

you can add as much fine grained caps as you want see, disco info from upload.domain.org, httpupload service

has a whole dataform with fine grained settings

like max-file-size

.

Hi guys, I'm creating a MUC client and I'm trying to use XEP-0424: Message Retraction, but it is not working. Could anyone help with that? I posted the details on stackoverflow: https://stackoverflow.com/questions/59859845/how-to-retract-a-message-in-ejabberd I also posted it on the ejabberd official muc, but still did not get an answer. Thanks.

leosbrf, have you read the big red warning at the beginning of https://xmpp.org/extensions/xep-0424.html

I doubt any server supports 0424 tombstones. They are also not strictly required because the receiving client should receive both, the message and the retraction message

If you want to ensure the retraction message appears in MAM, you probably need add a store hint when sending it (`<store xmlns="urn:xmpp:hints"/>`)

thanks larma