jdev - 2026-04-05

The app will usually want to render it at font size. To make it look like an emoji

Yes, of course

Now that I can get by

an app basically never renders an image at the size specified in the file because UI constraints always apply. Especially in emoji case but generally also

Also by the way, can this ever be used in places like reactions?

but if I use the same image as a sticker the app may render it differently of course. None of this affects protocol

I think reactions need a Unicode emoji

I use it in reactions but not with reaction xep

So snit, I'll be modifying the ProtoXEP to remove any mentions of packs, and instead in Implementation Notes, recommend that implementations implement 0449 and use that as emoji packs if they want

and also change the ID in <emoji> to use the first hash of the SFS/SIMS element

is there a standard way custom emoji should be sent in XHTML-IM without allowing all inline images?

Nobody wants to use XHTML-IM

that's clearly not true

Whether it's true or not, It doesn't matter because that's not related

This ProtoXEP is about Message Markup

> is there a standard way custom emoji should be sent in XHTML-IM without allowing all inline images? Not sure I follow. Custom emoji are inline images ↺

sure but they have a specific (client-dependent?) size

We don't rely on the size being in a certain range

Like singpolyma said before, emojis can be of any size, even a sticker

that's two sizes

Right. Client needs to size them sanely in UI this is up to client to do

Maybe you could use the CSS in XHTML-IM to size them back down to font size

you need to assume the native "size" (resolution) of the image doesn't match the size you want to display

But I don't really know

I don't think that's really needed but our could. I apply sane sizing for all inline images

obviously I don't want someone to send an "inline image" dhsd actually renders huge. No matter what is in the file or html or css

> I don't think that's really needed but our could. I apply sane sizing for all inline images How do you handle font sizes in XHTML-IM? ↺

Do you have a cap for how large text can be?

Depends on the app. I'm most of them I don't support font size control beyond "this is smaller" (aka <small>)

I may remove all inline CSS support from all of them entirely I haven't decided. At least colour I know biboumi uses so I support that everywhere at the moment

or no, not iOS. Just android and web

but I probably would add it I'm not sure

singpolyma: Can you review https://codeberg.org/techmetx11/xeps/src/branch/master/emoji-markup.xml now?

you don't want multiple version blocks in a protoxep For hash maybe use a hash child element from the normal namespace instead of an attribute named id? I'm not a messaging markup person but pretty sure you want a span element parent not begin/end on the emoji child

I'd also avoid the old jinglepub thing in the example for simplicity etc

> you don't want multiple version blocks in a protoxep > > For hash maybe use a hash child element from the normal namespace instead of an attribute named id? > > I'm not a messaging markup person but pretty sure you want a span element parent not begin/end on the emoji child No multiple version blocks? ↺

So like, just one?

I did update it again per your other recommendations

singpolyma: Does it look fine now?

> So like, just one? Right ↺

looks great

> So snit, I'll be modifying the ProtoXEP to remove any mentions of packs, and instead in Implementation Notes, recommend that implementations implement 0449 and use that as emoji packs if they want that'll work for me yeah. do you think it might be an issue that it only specifies SFS, or are we just assuming it allows SIMS data too? ↺

sorry haven't been keeping up so might be a stupid question lole

>> So snit, I'll be modifying the ProtoXEP to remove any mentions of packs, and instead in Implementation Notes, recommend that implementations implement 0449 and use that as emoji packs if they want > that'll work for me yeah. do you think it might be an issue that it only specifies SFS, or are we just assuming it allows SIMS data too? It doesn't specify SFS only anymore ↺

It's either SFS or SIMS

sorry, by "it" i meant XEP-0449 packs

Ah

Well I don't think it matters

wouldn't it matter for all the same reasons the markup protoxep allows both?

I guess it would or implementations would just refuse to implement 0449

i guess worst case scenario i can just bug the author of 0449 about making it more generic lole

and if they don't wanna then seems like a good excuse to write my own SIMS extension to it

Submitted a PR in the XSF github

huge wins for the custom emoji community

> if anyone wonders, i tracked it down its chunked http encoding but http libraries/clients deal with this, how was it getting prepended to the file? ↺

> Submitted a PR in the XSF github okay just getting around to reading it (should've done this before you submitted): * "the &lt;emoji /&gt;" needs a capital "The" * "it MUST include one or more &xep0300; &lt;hash /&gt; elements to identify the specific emoji" should probably clarify that the hash obviously has to match one listed in the file metadata lole * we're doing it in the <span />? i thought we decided against that * the implementation note lists two unrelated points as a single sentence, which i find odd. i also think the point about scaling the emoji is just a given and i don't think a protocol specification needs to tell the client they can scale down a 4k image to fit it in the UI * the changelog says there're notes about bob, but i don't see any * dependencies need to be updated. we no longer depend on BoB (depending on the missing notes), and it might be good to add SIMS/SFS as a dependency maybe, and definitely XEP-0300 since we use it no matter what * abstract mentions SFS but not SIMS * might be worth clarifying use of the 'id' attribute with SFS, even if its just "id can be anything as we don't use it at all" ↺

> okay just getting around to reading it (should've done this before you submitted): > * "the &lt;emoji /&gt;" needs a capital "The" > * "it MUST include one or more &xep0300; &lt;hash /&gt; elements to identify the specific emoji" should probably clarify that the hash obviously has to match one listed in the file metadata lole > * we're doing it in the <span />? i thought we decided against that > * the implementation note lists two unrelated points as a single sentence, which i find odd. i also think the point about scaling the emoji is just a given and i don't think a protocol specification needs to tell the client they can scale down a 4k image to fit it in the UI > * the changelog says there're notes about bob, but i don't see any > * dependencies need to be updated. we no longer depend on BoB (depending on the missing notes), and it might be good to add SIMS/SFS as a dependency maybe, and definitely XEP-0300 since we use it no matter what > * abstract mentions SFS but not SIMS > * might be worth clarifying use of the 'id' attribute with SFS, even if its just "id can be anything as we don't use it at all" :( ↺

sorry luckily most of those are editorial changes lole

but singpolyma told me to put it in a span

oh okay

yeah like i said earlier i don't mind either way regarding spans

Marvin is the one to ask there but that's my understanding of how span should be used

i wish 0394 was more clear about what specifically that element even does

> sorry luckily most of those are editorial changes lole is it good enough noooooowww ↺

> is it good enough noooooowww i have devastating news ↺

you did the entity for XEP-0385 incorrectly in the abstract, so now the file isn't going to validate

but other than that yes that should be good

also out of curiosity what was the BoB note going to be?

> also out of curiosity what was the BoB note going to be? The implementation notes you put ↺

What I meant by "BoB notes" were the stuff you put about that

> you did the entity for XEP-0385 incorrectly in the abstract, so now the file isn't going to validate FUUUUCCCCKK ↺

> What I meant by "BoB notes" were the stuff you put about that oic ↺

What do I do?

If its not gonna validate, are they gonna close the PR immediately?

> FUUUUCCCCKK for future reference if you run `xsltproc xep.xsl protoxep.xml` in the base of the xsf/xeps repository and it'll convert it to html for you but more importantly it'll tell you if its broken ↺

> If its not gonna validate, are they gonna close the PR immediately? probably not they'll just ask you to fix it or do it themselves ↺

you just need to add the leading 0 to the number

>> FUUUUCCCCKK > for future reference if you run `xsltproc xep.xsl protoxep.xml` in the base of the xsf/xeps repository and it'll convert it to html for you but more importantly it'll tell you if its broken I think if you run the makefile it does this for you also ↺

WHAT

holy moly i didn't even realise there was a makefile

this should probably be added to XEP-0143 because right now it just suggests running xsltproc manually

RE SFS vs SIMS: from my understanding, the biggest advantage of SFS from a user perspective is that you can send multiple files in the same message, while being backwards compatible with clients that implement only oob

snit: https://github.com/xsf/xeps/blob/master/docs/REPOSITORY.md

О

snit: what did you do after you submitted the protoXEP?

> RE SFS vs SIMS: from my understanding, the biggest advantage of SFS from a user perspective is that you can send multiple files in the same message, while being backwards compatible with clients that implement only oob You mean the attach-later thing? Technically you could do that with sims but it's true SFS added that more recently as an idea so if people want to go with that style it could be considered another difference ↺

> snit: https://github.com/xsf/xeps/blob/master/docs/REPOSITORY.md oh nice lol. both readmes mention that directory being for the editor so i promptly ignored it 💀 ↺

Yep, same thing here. Should be linked from the main readme

> snit: what did you do after you submitted the protoXEP? i just waited a week or two for it to get merged (which seems to be on the same day as the council meeting where voting will start) and then once the voting starts you get to battle the standards@ readme 😈 ↺

usually for two weeks or if you're special like me 😎 you'll get three

>> snit: what did you do after you submitted the protoXEP? > i just waited a week or two for it to get merged (which seems to be on the same day as the council meeting where voting will start) and then once the voting starts you get to battle the standards@ readme 😈 Oh so I have to wait :( ↺