jdev - 2026-04-04

i remember discussion a while ago regarding XEP-0511 and the fact that the metadata could be sent in a separate message from the one(s) containing the link. do any clients actually support this, or will it only display if the message contains both the link and the metadata?

ideally they'd be sent at once, but a room i'm in has a bot for fetching link previews, but its kind of spammy and it'd be a lot better if it could just quietly send the metadata on any messages that don't already have metadata attached

should really be a muc module so it can just add it to the message but i mean i'm not the room owner nor the bot writer 🤷

sounds like a problem, why would i accept meta data from another entity than the contact

because not everyone sends metadata and the obvious solution is for the muc to just send it for you. surely you trust the muc service or people running the muc more than some random guy, right?

What are you proposing, every admin of a room can attach stuff to my messages?

such a spec could exist, but i dont think it would turn out the way you would want, as when other people attach something, it would again need to be clear in the GUI who attached what at what time

further its problemtic because the person sending the message cannot remove stuff others attached

> What are you proposing, every admin of a room can attach stuff to my messages? i mean in this specific scenario the admin's already using a bot to send metadata anyways. i guess the only benefit here is its already obvious who fetched it, but now i get to be spammed with useless messages i can't turn off like i otherwise could've :) ↺

> further its problemtic because the person sending the message cannot remove stuff others attached yeah? of course they wouldn't be able to delete something they never sent ↺

ok but why would i should it then as part of my message in the GUI?

what you are trying to solve, is a client displaying your bot messages as separate from the original message

what i am trying to say, even if a client would implement "attaching" they still would make it clear, that the message comes from somewhere else, and they problaby would make it clear that these are separate things

everything else would be a venue for abuse

> what i am trying to say, even if a client would implement "attaching" they still would make it clear, that the message comes from somewhere else, and they problaby would make it clear that these are separate things this is honestly better than the alternative i'm apparently going to have to propose to this admin ↺

which is to write a muc module that adds it to the message itself as if the user sent it

you are saying its better, without seeing any proposal for the GUI in a client

don't we already have link previews tho

i don't need to see any actual proposal to know "externally-attached metadata that's clearly marked as such" is better than "externally-attached metadata that pretends its been added by the sender themselves"

> don't we already have link previews tho yes but we're talking about a specific use-case of them ↺

your "MUC adds it" proposal would not work in Gajim for the client who sends it

Gajim does not except data that a MUC adds to a message

which would make it so that everybody could see the link previews, except the client who sends it

oh cool so now not only is the muc able to attach whatever it wants as if the sender did it, but now the sender doesn't even get to know!

Yes, you can do a lot of things if you have control of the server, you could even send different messages to different occupants :)

this seems very counterintuitive when we could've just had a slight ui change to show who sent the metadata, and then mucs can send it as themselves and now everyone knows it was the muc

i think this was all discussed, every mode has drawbacks

instead of actively ensuring the muc is only ever able to use the most destructive means to achieve this without the sender even knowing

your way is not "better", it just has different drawbacks

nobody forces you to do this

test

i mean some MUC modules already add metadata or even modify message content. an example being pastebin

> instead of actively ensuring the muc is only ever able to use the most destructive means to achieve this without the sender even knowing i genuinely can't see how the drawbacks of this aren't so much worse than the drawbacks of sending metadata separately ↺

in one case the muc actively masquerades as a user and their client specifically ensures the end-user never finds out, while in the other, the client dev has to make a slight ui change

hey, i guess if you MUST make everybody see link previews right NOW. then you have only bad options :)

ironically enough, the reason i brought this up is because i'd prefer if the room's bot i mentioned had previews i could turn off like any others

> i mean some MUC modules already add metadata or even modify message content. an example being pastebin yes, and they break stuff with it, for example fallback indications that reference character ranges ↺

i had to add sanity checks for that

i genuinely don't want to see them they're annoying as hell but i'm not the room owner nor am i the bot writer, so the only thing i can do is try getting them to use XEP-0511 instead of spamming plain messages

or you can leave the chat, or you can tell them to stop it

so if i can't have normal ux and their bot can't send metadata itself, then i'll just have to encourage writing a muc module 🤷

no you can just stop sending link previews :D

what is this, link previews did not exist a few months ago and everyobdy was fine

> no you can just stop sending link previews :D yeah I WISH ↺

then use a client like Gajim and block the bot

or solve the problem "Someone sends something i dont want to see" in a generic way

> then use a client like Gajim and block the bot sure, if this was all the bot did, but its not ↺

what if all clients implement preview attaching, and you are happy, but suddenly the bot sends a different message you dont want to see :D

gajim already has an option to turn off link metadata display i really don't get why i would block the bot when it could just be sending link metadata

im happy that this problem does not exist then in Gajim

the thing that bothers me is if people do not solve the root cause of a problem, only the symptoms

the problem seems to be that not all clients send link preview, maybe that is the users choice or maybe they dont implement it

so now someone writes a bot, instead of implementing it in clients

> the thing that bothers me is if people do not solve the root cause of a problem, only the symptoms what like how they don't want to make a minor ui change, thereby forcing anyone desiring server-side link metadata to edit the user's message directly instead of making it obvious it was sent by the server? ↺

and now that bot bothers you, so now we should implement stuff again to counter the bot problem

thats all a bit crazy or

i think we should just have link metadata that the client sends itself

the problem starts with writing a bot to attach something a user chose not to send

there is the first and biggest problem, everything else follows afterwards from this error

> the problem seems to be that not all clients send link preview, maybe that is the users choice or maybe they dont implement it sure until a room admin decides they don't trust users to send metadata and would rather just replace it all with their own metadata ↺

and again now they're forced to attach it by pretending to be someone they're not

no, nobody is "forced" to do anything

its not a necessity to have link previews

yeah like how nobody is forced to use xmpp at all i guess they could just live with subpar solutions they don't HAVE to do what they'd prefer to 🤷

i don't think this discussion is particularly productive though at this point. i just can't see the logic in arguing against externally-added metadata plainly marked as such in favour of just praying and hoping server/muc owners don't just pretend to be the sending user directly

i did not argue in favor of the other solution, i think both are bad. I have a third option you seem to not consider. Clients sending the link previews if they want other people to receive them

as multiple clients already do

clients don't get to control what server/muc owners do, and so long as they don't, that's not a solution and is still just the praying and hoping part

https://xmpp.org/extensions/xep-0367.html

i find the use case "this makes my preview bot nicer" at the moment not convincing enough to add this in Gajim

cool then i'll just suggest editing the message directly i guess

good thing they can edit it to whatever they want and they sender will never know if they use gajim!

But Gajim already sends link previews by default ...

Also im not the authority of xmpp, i just told you my opinion about such a feature at this point in time

you may talk to other client developers first, and it did happen many times in my life, that after some time my opinion changed, its not impossible

> But Gajim already sends link previews by default ... okay? not everyone uses gajim. not everyone leaves them turned on. not every server/muc operator will leave them alone even if attached. nothing i can do will stop someone who wants server-side link metadata from doing server-side link metadata. the most i can do is encourage clients and servers both to use the best option, which in this case is allowing the server to send the metadata separately so that clients are aware it doesn't come from the original sender ↺

> you may talk to other client developers first, and it did happen many times in my life, that after some time my opinion changed, its not impossible sure, and i intend to now that i have confirmation that we can't just agree to do this client-side, but "one of the biggest desktop clients already said they won't support it" doesn't inspire much confidence ↺

best i can say is my client's going to support this obvious safety feature when it gets to that point, and Sunglocto: i encourage yours to as well

not like it matters though if operators know half their users won't be able to see it because one majour client doesn't support it and thus don't use it 🤷 ✏

a muc module is obviously the best solution and I'd like to write one of two options there similar to my recent cache media module. However if the bot sehds link previews while I won't attach them do the original message I will show them in their own message which is the timing is close may be still nice and nicer than a raw message

The best thing about XMPP is that _everyone can do what they want._ The worst thing about XMPP is that _everyone can do what they want._

Hi everybody

What are the prerequisites for someone who wants to develop a Pyside-based XMPP client?

Pyside is Qt binding to python

You probably need to find first a python XMPP library

Write a client that can connect to a server, and then start to build a GUI with Qt

Hi lovetox, thank you for the reply, i already have found a python xmpp library called slixmpp, it is a fork of sleekxmpp

But its documentation only explains well how to create a bot which connect to a server, so yes, they explain how to connect to a server and send message or receive one but there is no explanation about how to fetch roster for example

I can start for now by creating a client that connect to a server but i don't know how to do the rest

you need to read the code, and the specs

you can also check other clients that use the library

one i know of is for example poezio

Can you send a BoB URI in SFS? (XEP-0447)

I just see references to HTTPS URLs and Jingle

Maybe you can but I doubt anyone supports that. If anyone is supporting SFS yet

> Maybe you can but I doubt anyone supports that. If anyone is supporting SFS yet Don't you in Stickers? ↺

No. SFS is one of my no never XEPs

I like SFS because it has the hash of the content alongside the URL

Which allows for caching even if another server hosts it

So does SIMS, which SFS is a clone of

I wonder why does Stickers use SFS then

The sticker store xep? Probably because the xep author liked that or was unaware

> The sticker store xep? Probably because the xep author liked that or was unaware Marvin is the author of both XEPs ↺

That would make it pretty simple then 🙂

> No. SFS is one of my no never XEPs Well it seems like the only reason why SFS was made was that SIMS relies on the (unrelated) Jingle XEPs for the metadata namespace ✏ ↺

SFS instead relies on XEP-0446 for the file metadata

Right. This is the main problem I have with SFS. It invented a new namespace for data we already had a namespace for and then claimed this was an improvement

no, please be serious

first the author made the effort to add a list directly at the start

> No focus on media, generic for every file type. > Body can be used for fallback. > Using File metadata element (XEP-0446) [2]. > Using XML for structured data instead of URIs when possible, adding further extensibility (like providing proper means of sharing encrypted files on http servers). > Not relying on underspecified usage of References (XEP-0372)

Question on old unapproved XEP Instant gaming https://xmpp.org/extensions/inbox/instant-gaming.html#1to1-invite Why the invitation is a message but not the IQ? I can understand why other game moves are messages: it's kind of not needed for a response. But for the invitation it looks like a better choice would be an IQ request-response

doesn't IQ expect a relatively immediate response from someone who's already online? maybe its a message so you get a notif, come online, and respond after a few minutes

game invites as messages would also match how steam does it

Makes sense. Also maybe the IQ is intended for C2S but not C2C. Or maybe that's for interoperability reasons, as far I understood the IQ were dropped at that times (maybe by the GTalk?)

>> No focus on media, generic for every file type. >> Body can be used for fallback. >> Using File metadata element (XEP-0446) [2]. >> Using XML for structured data instead of URIs when possible, adding further extensibility (like providing proper means of sharing encrypted files on http servers). >> Not relying on underspecified usage of References (XEP-0372) The first two in this list are not differences since sims is the same (generic and use body fallback) so yeah the difference is using xep0446 which I am against ↺

> Question on old unapproved XEP Instant gaming https://xmpp.org/extensions/inbox/instant-gaming.html#1to1-invite > > Why the invitation is a message but not the IQ? I can understand why other game moves are messages: it's kind of not needed for a response. But for the invitation it looks like a better choice would be an IQ request-response What even is this XEP ↺

To play Tic-Tac-Toe or Chess with a friend. There was a plugin for Piding called Instant Gaming. The Psi and Spark clients also have games so I going to make them use the XEP

> Makes sense. Also maybe the IQ is intended for C2S but not C2C. Or maybe that's for interoperability reasons, as far I understood the IQ were dropped at that times (maybe by the GTalk?) you can IQ another user, but you can only reliably expect that to work in 1:1 contexts, since i believe MUCs don't usually forward IQs between participants unless explicitly supported ↺

>> Question on old unapproved XEP Instant gaming https://xmpp.org/extensions/inbox/instant-gaming.html#1to1-invite >> >> Why the invitation is a message but not the IQ? I can understand why other game moves are messages: it's kind of not needed for a response. But for the invitation it looks like a better choice would be an IQ request-response > > What even is this XEP I think technically were supposed to call it a protoxep ↺

>> Makes sense. Also maybe the IQ is intended for C2S but not C2C. Or maybe that's for interoperability reasons, as far I understood the IQ were dropped at that times (maybe by the GTalk?) > you can IQ another user, but you can only reliably expect that to work in 1:1 contexts, since i believe MUCs don't usually forward IQs between participants unless explicitly supported They do. But they may not in the future ↺

it'd certainly be nice if MUCs allowed arbitrary IQs between participants :)

tbh half the things i think i want to try drafting expect an IQ and then i'm like "damn that'd make this basically useless in MUCs at first and inconsistent at best later on :(("

Well they do for now

oh they do?? sorry i guess i misread your message

the problem is that the IQ goes to a "random" resource

so depending what you're doing it's kinda busted and annoying

and really the only solution is to just not support it anymore. Which may happen in future

i was under the impression that MUCs don't usually forward IQs between participants unless they're explicitly configured to allow the IQ you want

sounds like i should just keep assuming that's the case then if it could just disappear

They usually forward all IQ unless configured specially to not

and then there are heuristics to try to guess which iq should go to bare jid instead (eg for vcard and pep) ✏

if you have a good use case for this and it's something that can actually work with the random resource thing I'm sure it would be good for people to know about it

Is there a XEP for moving identities between servers easily?

I wouldn't say nomadic, but close to it

> Is there a XEP for moving identities between servers easily? There is XEP Move

https://xmpp.org/extensions/xep-0283.html

> The first two in this list are not differences since sims is the same (generic and use body fallback) so yeah the difference is using xep0446 which I am against only if you abandon what we are doing now (body and oob, same), which i agree has probably not the biggest benefit ↺

but the biggest problem with SIMS is, that there was no update since 2018, All the problems listed are real, its just not in good shape at all

i dont see how this gets chosen over 447 at any point, simply because its design wise not good, and has no active author ✏

Re-using a namespace from a deferred XEP, how does that make sense for a XEP that tries to be the future of file sharing, maintaining a separate XEP for file metadata, in a generic way which is not linked to a specific file transfer XEP, makes sense to me

and yes sims focuses on specific media, https://xmpp.org/extensions/xep-0385.html#sect-idm45875373773024

which is .. not necessary at all, the whole section can be gone

thank you for your advices lovetox

> and yes sims focuses on specific media, https://xmpp.org/extensions/xep-0385.html#sect-idm45875373773024 they suggest some formats to support as a baseline. Doesn't prevent anything else from being used as well? ↺

I agree we could remove that section realistically

> i dont see how this gets chosen over 447 at any point, simply because its design wise not good, and has no active author It's the same design but better namespace reuse ↺

If sims needs changes we can easily make those. It's a webpage under XSF control after all 🙂

but why should anyone? If you have two competing standards, you need to bring more arguments to the table then just "i was here first" and "maybe sometimes in the future, somebody can fix the things not good"

if we would do a Last Call today, it would not get approved

Maybe i should indeed request Last Call for both, so we dont need to discuss this anymore

Neither has enough implementation to support a last call

how much does it need? 2?

but yeah I don't really know how to be more clear. SFS cut and pastes SIMS and changes the namespaces with less reuse then documents this as good. Seems like an obvious worst choice

Why should a iteration be worse

you make it sound like, "copying" is something bad in this context

Copying instead of fixing is bad. But in this case the only change isn't a fix it's to remove the xmlns hygiene and reuse so it's worse on that basis

there are reasons for not re-using the Jingle namespace, its a very old XEP which sees no updates anymore, and it makes design wise not much sense why Jingle should host forever all file metadata

if sfs used the jingle namespace or some other pre existing namespace instead then it would be mostly fine. But then it would just be sims with no changes... ✏

thats the nature of an iteration, that it is mostly the same

again my main complaint is the the change made is a bad change

why is it bad to have a XEP that defines file metadata without being tied to any other XEP?

because it fails do reuse an existing namespace when one exists with all the desired semantics

thats called factoring something out, that we know we want to update in the future and we right now know is very likely to be used in future XEPs

i mean you surley know this from programming

its not that different

One could argue jingle is bad and we should use one of the 4+ other standard formats like https://www.rfc-editor.org/rfc/rfc5854 and I'd be interested in such a discussion. But making yet another new one is just always bad

yes why not

though it would be a new XEP anyway probably

even if it reuses some other standard

XEP-0449 inherently depends on SFS, right? or is there a way to make it work generically?

also singpolyma, according to the xmpp page, both specs have 6 impl

so i think thats more than enough to make a last call

> XEP-0449 inherently depends on SFS, right? or is there a way to make it work generically? 0449 is a basically "you could put things in pubsub if you want" and the things it suggests is SFS. I could suggest something else. But I'm not sure if anyone has a real use in mind for it anyway ↺

well cynthia and i were working on custom emoji markup for XEP-0394 and a lot of the functionality XEP-0449 specifies would be really easy to build off of for our purposes, but it only seems worth it if we can be generic when the ecosystem is so fragmented

like how both of these formats attempt to be generic about where the file comes from, apparently now we need to be generic for the format for being generic about where it comes from 😭

We can't be generic about everything :P

yeah you have to make a choice eventually on certain things, but in this case i think we could just allow packs to just specify either/both SIMS and SFS variants if they want

Custom emoji doesn't benefit from anything from 0449? You need some way to specify a file (probably by hash) and where it goes. What would 0449 have to do with it?

> Custom emoji doesn't benefit from anything from 0449? You need some way to specify a file (probably by hash) and where it goes. What would 0449 have to do with it? what snit meant is that we based some things off of 0449 ↺

not that we rely on it

the format it uses for sticker packs can be adapted wholesale for generic packs of media files, like emoji packs

the biggest thing you'd have to change is replacing the <sticker /> element in messages with our markup element, really

> the format it uses for sticker packs can be adapted wholesale for generic packs of media files, like emoji packs I already used SFS, like 0449: https://codeberg.org/techmetx11/xeps/src/branch/master/emoji-markup.xml ↺

I'm wondering if I should change it to SIMS

> I already used SFS, like 0449: https://codeberg.org/techmetx11/xeps/src/branch/master/emoji-markup.xml some notes: <emoji /> should be in <span /> i think so it can just inherit its start/end rules. node+jid should might need to be required in MUCs unless there's some other way of knowing what node to access that i'm missing. also i still think bob is the idea file transfer mechanism for emojis so explicitly showing it in an example might encourage implementations to take it into account ↺

how does SIMS do multiple files? does it have something like SFS's 'id' attribute?

it simply multiple <media-sharing> elements

there does not need to be an id, because nothing references a single item

well in the case where someone sends multiple emojis in a message, there needs to be a way to figure out which file goes to which markup section. SFS solves this by just putting the same 'id' attribute in the <file-sharing /> and <emoji /> elements

i guess you'd just have to use the hash

add it to the list of things in SIMS that you can mention during last call

can definitely do that if there's not already an established way people can enlighten me about

i am not sure a sticker should ever be in a markup, it seems a sticker is ment to be send standalone

> The sending entity SHOULD use the <file/>'s <desc/> content as the message body

yes this is why we're not using stickers and instead using our own thing

just that stickers already do a lot of what we already want so its good to point at

but yes with markup, you certainly need something to identify the sticker

i'm assuming SIMS requires at least one hash so i assume that's enough

>> I already used SFS, like 0449: https://codeberg.org/techmetx11/xeps/src/branch/master/emoji-markup.xml > some notes: <emoji /> should be in <span /> i think so it can just inherit its start/end rules. node+jid should might need to be required in MUCs unless there's some other way of knowing what node to access that i'm missing. also i still think bob is the idea file transfer mechanism for emojis so explicitly showing it in an example might encourage implementations to take it into account I learnt that BoB has a pretty strict file size limit ↺

About 8KBs from SIMS page

That is a lot smaller than the ideal 256KB

i think you can safely ignore such limits

In any regard, you can shove a BoB uri as one of the <sources> ✏

> well in the case where someone sends multiple emojis in a message, there needs to be a way to figure out which file goes to which markup section. SFS solves this by just putting the same 'id' attribute in the <file-sharing /> and <emoji /> elements Just use the first <hash> of a <media-sharing> at that point ✏ ↺

snit: Also <span> is for inline markup, it doesn't make sense to put the emoji there since it'll take over the text

You cannot apply bold, italics or monospace to a emoji

Oh wait "Spans MUST NOT overlap each other"

> I learnt that BoB has a pretty strict file size limit BoB doesn't impose limits but it has some recommendations: > The <data/> element MUST be used only to encapsulate small bits of binary data and MUST NOT be used for large data transfers. Naturally the definitions of "small" and "large" are rather loose. In general, the data SHOULD NOT be more than 8 kilobytes, and dedicated file transfer methods (e.g., SOCKS5 Bytestreams (XEP-0065) [5] or In-Band Bytestreams (XEP-0047) [1]) SHOULD be used for exchanging blobs of data larger than 8 kilobytes. However, implementations or deployments MAY impose their own limits. ↺

Yeah 8KBs, so no animated or large emojis

I don't wanna try my luck at going beyond that recommendation because I don't wanna hit a S2S or C2S stanza size limit

> You cannot apply bold, italics or monospace to a emoji i think you definitely could but whether your font supports that is another matter ↺

No, you can't

To a custom emoji I mean

Since they are purely raster images

oh right i might be retarded i am distracted rn sorry

> oh right i might be retarded i am distracted rn sorry Thus, why should we put it in a span? Unless to avoid other markups overlapping with it? ↺

hm anyways i prefer it in <span /> but idm either way i just think <span /> already has most of the rules we already want regarding ranges

also i guess you could be bolding the fallback text 🧌

I think we should put the overlapping rules in the ProtoXEP, and not use a <span>

So even if a client doesn't support it, the markup will be interpreted as normally

(and a client that does support it, will ignore any markup that includes the emoji in its range)

> So even if a client doesn't support it, the markup will be interpreted as normally wdym? ↺

> wdym? Say if I put :pondering: in a monospace font, but at the same time, as an emoji (in a non-compliant client) ✏ ↺

A client that supports the XEP will ignore the monospace markup and only show the emoji

While a client that doesn't, shows the monospace markup

actually i take it back it shouldn't be part of span

it occurs to me that i might do `*GUYS :omg: GUESS WHAT*` and that'd put an emoji element's range entirely contained within a span's range, which i think is allowed but would be weird with two spans

>> the format it uses for sticker packs can be adapted wholesale for generic packs of media files, like emoji packs > I already used SFS, like 0449: https://codeberg.org/techmetx11/xeps/src/branch/master/emoji-markup.xml My biggest feedback here is it should not mandate any "pack" or pubsub thing but allow any custom emoji to be sent. Referencing the media in some way is needed of course, I would suggest by hash is sufficient. Including sims or SFS as is done here so that so specific ways of resolving the hash are suggested seems fine ↺

Alternatively could nest the sims or SFS element inside the span. That's maybe what you actually want and would follow the example from sims which no one actually implemented

true i guess it shouldn't mandate a pack but i do think there should be spec for packs that we can share around and import/export, maybe in a separate proposal?

That's what 0449 is

the reason I never pursued it is that no packs in that format actually exist. So I implementeh stuff like a signal sticker importer instead ✏

> Alternatively could nest the sims or SFS element inside the span. That's maybe what you actually want and would follow the example from sims which no one actually implemented What if someone used the same emoji multiple times ↺

You'd be making redundant SIMS/SFS elements

That's a good point. So maybe there's a reason to do the by hash version

I use Cid uris in XHTML-IM but have considered migrating to ni URIs. Both of which are just ways of writing hashes, so equivalent to this

If we used SFS, we would make the id attribute use the id of the <file-sharing> element

If we used SIMS, we would make the id attribute use the hash of the <media-sharing> element

Maybe we could use the hash in both cases, so that it's up to the implementation to use either SFS or SIMS

Right. If you use a hash you can use SFS or sims or both or neither

Really, I don't care, but I'd like people to agree which one to use in the mailing list so that implementations don't have to implement both

> Right. If you use a hash you can use SFS or sims or both or neither Speaking of, do either support BoB URIs? ↺

Yes both do. But if the hash is there it's a bit redundant

since a Bob Uri is just a funny way to write a hash ✏

I'll be changing the id attribute to use the first hash of the SFS/SIMS element

But the examples will still show SFS

singpolyma: Would this be fine?

Add hash and remove pack sounds like an improvement for sure

I'll make pack optional

Honestly I was gonna do it because it felt simpler to do so

But I saw 0449 had a pack format and so I had to do it :P

Honestly how many people want the pack thing anyway

Vote!

i'd like packs personally, but i don't care how or where it gets specified or if we just use XEP-0449, just as long as i can upload groups of emojis and share them lole

I was thinking of like, being able to right click and copy any emoji to your local storage ✏

Though I find the <restricted> part of 0449 to be dumb

> I was thinking of like, being able to right click and copy any emoji to your local storage yeah this'd be nice too but i also have several emojis i like to upload as groups that honestly make most sense imported all at once ↺

Maybe we could spec a emoji pack file format ✏

for example i exported all of the toki pona discord's custom emojis and i can use them as a group in matrix and it'd really suck if someone wanted to use them and had to manually save each one and reupload them lole

How does Discord's emoji pack format work?

If it even has one

uh its just a per-server thing and you're not really able to export/import them

i just did it manually lole

Nobody cares about what Discord thinks

I know with a custom client, you can scrape their API for a guild's custom emojis

> for example i exported all of the toki pona discord's custom emojis and i can use them as a group in matrix and it'd really suck if someone wanted to use them and had to manually save each one and reupload them lole So I did look at a site and it turns out people tend to stuff emojis into a ZIP file ↺

and call it a "pack"

So really, if you want to upload a custom emoji pack, your client SHOULD support ZIP files as a pack of emojis ✏

i don't know why we wouldn't just use pubsub for this though your client could just copy the node's info into your own pep node and optionally also add/replace new file sources if needed

Just like singpolyma said, it would be useless if nobody used it

you _could_ allow downloading as a zip file to get everything all at once when replacing the file sources i guess but idk if we need to do that really

Also having emoji packs be exposed as a pep node introduces additional issues like privacy

and stuff like that tends to overcomplicate implementations

Maybe emoji packs can be a seperate XEP

instead of bundled with the main custom emoji markup part

> Though I find the <restricted> part of 0449 to be dumb Well it's an experimental xep. So not meant to be implemented and can easily be changed before anyone does hopefully ↺

> Just like singpolyma said, it would be useless if nobody used it sure but i'd use it in axon at least ↺

> Maybe emoji packs can be a seperate XEP yeah that's fine ↺

> Maybe we could spec a emoji pack file format Zip file? Tarball? ↺

> Well it's an experimental xep. So not meant to be implemented and can easily be changed before anyone does hopefully When I read that at first, it reminded me of "you can't download a car" ↺

> Zip file? Tarball? Yes, ZIP files mainly but tarballs, sure ↺

> Maybe emoji packs can be a seperate XEP Already are, right? ↺

Most sites distribute emoji packs as ZIP files

Yeah

> Already are, right? What XEP? ↺

0449

> Also having emoji packs be exposed as a pep node introduces additional issues like privacy you should be able to just use other people's nodes if you don't feel comfortable putting it on your own PEP node. i assume if someone else is hosting it on theirs that they're aware of the privacy stuff lol ↺

Need to host the files somewhere also

> Most sites distribute emoji packs as ZIP files i'd expect this for export but not really copying to your own pep node personally, i'd just want a button when i click a sticker to go "view pack" and then "copy pack" and an optional "replicate files" or something ↺

> you should be able to just use other people's nodes if you don't feel comfortable putting it on your own PEP node. i assume if someone else is hosting it on theirs that they're aware of the privacy stuff lol So I want to have emojis that I want to use privately, I have to use it on my publicly-exposed PEP node? ↺

> Need to host the files somewhere also on matrix people actually just live with the file being hosted somewhere else when they import emojis and that seems to work for them, but yeah we could easily optionally allow copying to our own place ↺

> So I want to have emojis that I want to use privately, I have to use it on my publicly-exposed PEP node? uhhh i'm not sure how stickers does handles that i guess ↺

I'm supposed to use <restricted /> which is just telling people "pretty please do not import this pack"

It doesn't prevent them from copying the whole pack beyond the one sticker I posted

yeah nothing can stop a user from downloading images you've explicitly sent them lol

as with many things on xmpp, its a suggestion at best

I never explicitly sent them the *whole* pack

I only sent them one of the emojis/stickers in the pack

Just send it without a pack advertisement if you want that

which is what everyone does now

oh then just don't specify a pack when sending the emoji ig. considering the pack is apparently gonna be specified separately i imagine that'd be optional

> Just send it without a pack advertisement if you want that 0449 never specifies this, which is one of the issues I found with it ↺

> Additionally, the sending entity adds an element <sticker/> to the message. This element carries an attribute pack referring to the id of the pubsub item carrying the sticker pack. If the sticker pack resides on a pubsub item other than the senders personal eventing (PEP) node named "urn:xmpp:stickers:0", the sending entity must add additional attributes jid and node, referring to the jid of the pubsub node and the name of the node, respectively.

This sounds like a requirement, not a suggestion

>> Just send it without a pack advertisement if you want that > 0449 never specifies this, which is one of the issues I found with it 0449 is only about packs and advertising them. To send without a pack advertisement you simply do not use 0449 ↺

I see

So I don't feel like it should be good to cram in packs with the main custom emojis XEP

Maybe the packs should be a seperate XEP, snit

No. If you really want to you can say "if you want packs use 0449" but even that might be more than is needed. People can find it

Then 0449 should be modified to distinguish between emojis and stickers

those are the same thing from the pov of a pack ✏

the usage in a message is different

But it shouldn't be the same thing from the client's pov

Otherwise stickers can mistakenly be used as emojis

That's up to the client. It is for me. Every pack I allow to be used for either as the user perfers

> Maybe the packs should be a seperate XEP, snit yes I said I was fine with this or with just using 0449 packs just as long as I can do it at all lol ↺

I mean, lack of seperation would be a crappy UX but whatever

It's the client's thing, I don't care ✏

indeed. Every app will make a different choice which is good

If someone uses a giant emoji (e.g. sticker), I'll just resize it down to the text size

oh you definitely have to support that

Support what?

Isn't that a UI suggestion?

because an emoji in 16pt font on a 4k screen needs to have access to resolution you might not need at 12pt on 1080p

so you can't make any assumptions about file resolution in any case

Sooo what you're saying is, the emoji should be resized down to the font/UI size?

Or should it be unchanged?

By the app at display time yes

unless they have some reason not to. You don't need to mention it in xep but the normal case will do this of course

which one? 😵‍💫

which one what?

I specified 2 questions