Gajim - 2023-10-27

https://github.com/Syndace/python-twomemo fjklp

who supports omemo 2?

bruh OMEMO 2? What is going on

omemo 2 is here!!

I'm so excited

Do you know Gajim OMEMO-DR: https://dev.gajim.org/gajim/omemo-dr

Is gajim development team USA based?

Why do you ask

No

Why are you whispering

I'm located in the UK

> Is gajim development team USA based? It's EU based ;) ↺

OMEMO2 comes with Content Stanza Encryption, see https://xmpp.org/extensions/xep-0420.html

That's a lot more encrypted elements than before

Gajim uses its own OMEMO library, omemo-dr. Gajim is not ready yet for OMEMO2

it's over

Why do the following menus have three dots? Select Message... Quote... Delete Message Locally...

Three dots is used when a new window or dialog or confirmation dialog is open.

real

umu test

I rephrase my question: Why do the following menus have three dots? > Select Message... > Quote...

sch: yes they should not have the 3 dots

Okay. Thanks!

Select message though has a action afterwards

It's not a dialog

I thought: Three dots are appended if the action is not immediately carried out, i.e. there are choices or feedback dialogs afterwards.

"Quote..." for example is no immediate action, since the user gets to type a message while in quote mode

"Delete message locally..." also has a dialog asking if it really should be deleted. The three dots convey the message that this action is _not_ immediate

But maybe I got this wrong? :)

https://learn.microsoft.com/en-us/previous-versions/windows/desktop/bb246448(v=vs.85)

> Include an ellipsis (...) at the end of a menu command that opens another dialog box rather than immediately performing an action. The ellipsis is a visual cue that the user must supply additional information to complete the command. F

https://developer.apple.com/design/human-interface-guidelines/menus

> Append an ellipsis to a menu item’s label when people need to provide additional information before the action can complete. The ellipsis character (…) signals that another view will open in which people can input information or make choices.

> Select message though has a action afterwards oh so thats how to select multiple messages... telegram tries to be smart about it and just notice when you drag your mouse over multiple messages, which is nice if gajim *has* to do the separate text widgets per, uh, everything now

i noticed even citations (which i really wish would just revert back to a plain > prefix, the greyed colour is fine) have their own text widget

. ✏

oups wrong chat

cal0pteryx, ah thought quote is immediate, yeah then its fine i guess

opal, why would we show a ">" when we can format it clearly as citation?

because every client nowadays decides it wants to break kaomoji and other cases where a > at the beginning of the line may just be a > and not a quote

then add a space before or something, whats kaomoji?

you can also set it in ` asd ` tod disable formatting

i do add a space before, but a lot of us never asked for xep-0393 and theres a LOT of cases where this style of markup breaks the semantics of text where those "markup characters" are used

backticks are for preformatted text, not unformatted text

and more importantly, the backticks still show up and arent semantically correct how you suggest to use them in this case

it was overkill to completely scrap the idea of a subset of html formatting, years ago

and xep-0393 mimicks markdown without even including any part of markdown that makes it any bit still tolerable to use for chat input

there are no perfect solutions, and this one is 95% perfect ✏

close enough for me, personally i never ran into the problem you describe, where something *must* start with a ">" but is not a quote

how often does that happen? and why cant you enclose it with the code backticks ``` that we use for code?

then you dont quote posts from imageboards or use kaomoji or use it as a greater-than sign for a number at the beginning of input

because it isnt code

i believe the percentage you gave is based 95% off your own experience

a message board? that would be a regular quote? why do you need the >?

>>>/r9k/ >>12345678 >40% of people >_< all of those should not be cited

and now you see how ugly they look because i didnt put them in a code block, so i can share my pain with you

the current system is also horrible for accessibility mind you. there is no way to know structure or schemantics. because its just text.

lovetox, consider this: what stops a client from *optionally* allowing those plaintext characters to convert to <blockquote/> or <em/> or <strong/> or <pre/> or <code/>

MSavoritias (fae,ve), that a display thing, we could of course put every quote in its own box

then the XEP could be rendered useless and it would totally be up to clients to add these niceties, and we can go back to the xml formatting because this is an xml protocol anyway, so there arent any more parsing steps

i dont see how this changes something

you propose the client should automatically make everything a quote in xml?!

because then it makes it optional for the user to actually use it, optional for the client to support it (because it never has to parse *this* anymore, it'll just be xml)...

then you have the same problem

not if i disable the checkbox!

what checkbox?

Im not talking about display. Im talking about being able to know structure and schemantics of the text. For example there is no way to know if we are looking at a link as gajim right now besides parsing the whole text and trying to figure out if there is an https in there

right now 0393 is forced upon those who use clients that support 0393

there is zero way to escape this formatting, zero way to disable it

Which breaks with more protocols, and the amount of forward slashes etc.

MSavoritias (fae,ve), links are especially fun seeing how clients all do their own thing

0393 doesnt modify any text of the user, its sent as is over the wire

i think gajim takes <https://example.net/> with the ending bracket as part of the link

its exactly what you want

well, it did in MUC topics

As a person using gemini i dont even get nice things

and it still does in MUC topics

so, link parsing is irregular

please stay at one topic

>0393 doesnt modify any text of the user, its sent as is over the wire 0393 is a *client XEP* meaning *clients* modify the semantics of the text

this is one topic lovetox

it all has to do with text formatting and how utterly unreliable it is

no 0393 does not speak about links

ok but URI formatting was defined in some RFC somewhere long ago and gajim neglects that too

and > is never part of a URI, thats why we URI-escape it when its part of one

do not take personal offence to any of this, i see these problems in a multitude of software, not just gajim

i'm just stressing how fickle this kind of stuff is to implement

Yeah. Its yet another reason why the current markedown status quo is bad. The links that is. And its just an example of the many problems with it

it is easy to overlook a lot of this, i agree, and thats why i dont like adding more of it

i still dont see your argument, Gajim does not modify any text you type and send

and we probably never will

why are you so focused on the wire protocol here when this is a ui/ux XEP we're talking about

after all, it is a person who's looking at the effects of this XEP

not the tcp socket

we all agree on that, i believe

The problem was apparently, that using https://xmpp.org/extensions/xep-0071.html#security didn't work for many clients because it was too easy to implement it with giant security holes. That's one of the reasons there is now this simple alternative with its own downsides

its important because, its just a display function

we could simply disable it

ok hrefs are a valid concern, inline images are also a valid concern, which is why i would move to simplify 0071 if we were to reintroduce it in a modern context

Menel, see how activitypub implementations handle html scrubbing for an example of what could be done

thats seems like a good starting point

>we could simply disable it that would only fix gajim, and my point is that this applies to other clients implementing this exact same XEP to the letter

I'm no dev, I bet it is possible to make it right. But apparently some clients didn't, and that had real security issues. ✏

dino and conversations are both allergic to extra settings (and i can agree with the sentiment)

Menel, xhtml formatting also introduced design flaws into OTR parsing as well, so i understand

OTR implementations had to roll their own parser pretty much because it was a c2c protocol overlaid on xmpp, not really designed for xmpp specifically

and, parsing non-ciphertext in a crypto library is just wrong

especially with omemo we don't want inline images or other web requests to external resources, because that completely defeats the purpose of omemo, so, if i were to implement 0071 in a new client, i would just not support those things

So woud it fix your issue to disable formatting per message?

and for <a/> in specific i would expose the original uri if i was going to decide on keeping that tag

lovetox, no because other clients would still decide to format that message

it isnt my choice, it isnt gajim's choice, this is an xmpp ecosystem thing

I think you want to propose an alternative xep?

no actually not, its every clients choice, XEP is a protocol extension

it does not mandate UI

and im in the xsf/jdev mucs so i could bring this up here, but the topic just surfaced here, so here we are :)

The conclusion seems to be gajim can't do anything about it as long as we use that xep

lovetox, the only flag to enable styling seems to be client-wide with `<feature var='urn:xmpp:styling:0' />`

also nobody can force other clients to display something in a certain way, and if you want that thats already flawed in a decentralized eco system

and, gajim can disable that all it wants (globally) but conversations and dino and whatever else may not disable that

that's what i mean, by it isn't gajim's choice

Menel, correct

(on both your counts)

(and speaking of links, why is urn:xmpp:styling:0' linked)

notice the '

because its a valid uri

notice this too: `wowaname@volatile.bz`, i think the first backtick gets linked ✏

Then it seems it's time for </rant>

' is not a valid uri character

nor is `

well, let me double-check

you will be suprised :)

oh i often am when it comes to uris

gajims uri parser is compiant

what you want is Gajim to detect that you as a user dont want something included in the url even though its a valid char in the url

of course this is a endless endevour, though we added already many exceptions

https://www.rfc-editor.org/rfc/rfc3986#appendix-D.2 nah this claims ' is reserved

and in the case of `user@email.example` this never makes sense to mix the "styling" semantic of the backtick with the content of the preformatted text

yeah that could be improved

but ' is allowed in urls

security considerations for 0393 are definitely way less alarming than the ones in 0071, but the usability considerations may pose the story in a different light. that's what i'll say to sum this up

so you dont need the option to disalbe formatting in Gajim?

>but ' is allowed in urls guess i can take that complaint up to bloody RFC authors then :p

i use gajim as-is and just deal with the small issues, but i just provide insight here into random shit, take it all as you will

if i really cared then i would file a PR

opal: there is https://xmpp.org/extensions/xep-0393.html#disable

nice, we need to add this

oh cool

thanks hannibal i overlooked that

It's a pity that spoilers weren't incorporated in message styling IMHO.

I think it could be nice to have spoilers ||like this||, instead of needing something more sophisticated like XEP-0382

> i still dont see your argument, Gajim does not modify any text you type and send > and we probably never will This is actually the issue with 393. Wire format isn't decoupled from input format. You can't convey intent as a client. There is no way for the recipient to know if the message contains markup intentionally or not.

wait spoilers already exist? this is what PMR was asking about, right?

pep., that's a very good point, thanks for using better words than i ever could

That's always been my issue with 393. Plus the fact that you need to opt-in to opt-out, and I'm sure no one implements this as a recipient

pep.: opals case was that he wants no formatting, so no intent must be communicated

No, in 393 world you have to communicate that you don't want 393, otherwise formatting will happen.

https://xmpp.org/extensions/xep-0393.html#disable

But as I said I'm sure no one implements this

And that bloats every message that doesn't contain 393 because.

opal's a female given name btw lovetox

and that wasnt really my case, i just disagree with 0393 by principle, with how it exists currently

And to add to the above, obviously there's also no way to have messages with mixed intent with 393 ✏

> opal's a female given oh, ok i will remember for the future

i think you misunderstand the history of the XEP

It was never a replacement for 0071

Many clients did and do formatting of plain text messages, Gajim did that for 10+ years, other clients also

if i said or suggested it was a replacement, i apologise, but 0071 is still deprecated lol

The XEP just tried to find the common rules between clients and write them down

yeah that makes sense

XEP-0394 was the replacement for 0071

but no client seemed interested to implement it until now (at least i did not hear of any)

and that should also give you a hint how important this is to everyday usability ..

thats why i said, the current solution works for almost anything, certainly for the needs of the common user, for everyday communication

i agree that a XEP like 0394 should in the end be implemented by most clients

That 394 seems too complex imo. And im not sure it even solves the accessibility issues we already have

> de-facto a écrit : > gnome shell x11 or wayland?

394 really is a failed replacement for 0071. But apart from that, 393 is still an issue in that it forces the way stuff will be interpreted on the other side, even though the sending client doesn't talk that language

yep. i dont see why everything cant be xml like opal said /shrug

MSavoritias (fae,ve), accessibility is a UI topic, a XEP is wire format

both have nothing to do with each other

pep., but thats no because of 394, this was always that way

a receiving client is free to interpret a message how ever he likes

but a proper wire format can help a whole lot with accessibility. see the html accessibility for the http web for example

its the same exact argument as with html vs plain text

dont know about what argument you are talking

which information do you miss in the wire format that you think is needed?

for example: you have a person that needs a screen reader. right now the screen reader will read everything. as in star - text - star for bold. instead knowing its bold. its about schemantics knowledge. another example: you have a person that sees different colors. or wants to make *some* parts of the text bigger. there is no schemantic way to know what is actually what in the text to identify them. here is a quote from MDN: > One of the best accessibility aids a screen reader user can have is an excellent content structure with headings, paragraphs, lists, etc. An excellent semantic example might look something like the following:

http web has already understood the importance of properly communicating structure, context and schemantics over a decade ago. hence the initiatives for WAI -> https://www.w3.org/WAI/fundamentals/accessibility-intro/#context and xhtml even -> https://www.w3.org/TR/xhtml-access/

or for links again from MDN: > Links (the <a> element with an href attribute), depending on how they are used, can help or harm accessibility. By default, links are accessible in appearance. They can improve accessibility by helping a user quickly navigate to different sections of a document. They can also harm accessibility if their accessible styling is removed or if JavaScript causes them to behave in unexpected ways.

i think you missed something, 393 is just a way to interpret a messages as markdown. Text is simply send as plaintext over the web, no structure, no formating intent, nothing.

exactly. which is why i am saying its bad for accessibility and need a proper wire format :)

i was responding to the message that accessibility is a UI topic.

it exsits already https://xmpp.org/extensions/xep-0394.html

have a read

that a wire format can help a *lot* regarding accessibility. which right now we dont have it

and thats what im trying to tell you, yes we have it

> have a read i did. the accessibility is basically two lines.

compare that to the decades of html accessibility guidelines

it just passes as some NIH xep imo

so i ask again

what do you think is missing from 0394 that you need

and dont tell me about HTML, nobody implements the whole html spec for sending chat messages

i dont need to design a website, i need a few basic blocks like, bold, emphasis, quote, codeblock

im sure the XEP can be furhter amended if we learn that we need something additional

> i dont need to design a website, i need a few basic blocks like, bold, emphasis, quote, codeblock exactly. you need. what about for accessibility?

anyway ill drop until i have something more concrete to propose

but that xep shouldnt be passed at the current state imo

unless a serious accessibility research is actually done

maybe i dont understand whats so complicated about accessibility

we send a <quote>This is a message</quote>

what else needs to be added here?

if you just want to add a quote? nothing. but if you start adding more and more context and parameters you end up recreating html just with extra steps

because remember gajim is not the only application. we also have movim and libervia which are completely different to IMs

they are going to need more context. and then either you add everything on one xep and recreate html or you end up creating two markups. the "lightweight" and an html like

we can only send what the user gives us. And thats what im trying to tell, in IM there is not much to give, its just a message, and not a document like a website

And thats why xhtml was deprecated, because its a risk to add everything under the sun.

maybe. but the current approach goes too much on the other side

its easier to define specific elements that you need, a subset, than disallowing 90% of some other standard

and i thought we already established there is a lot in IM. for example: - pictures and alt - quotes, bold, italics - mentions - links - videos and alt - code blocks

quotes, bold, italics, codeblock -> is message formatting

everything else you wrote we have already standards for which are fine

the only thing that maybe missing is link formatting

"lovetox> i think you missed something, 393 is just a way to interpret a messages as markdown. Text is simply send as plaintext over the web, no structure, no formating intent, nothing." And the thing that's annoying in this debate is that you make it seem like it can be both at the same time, when many clients actually removed support for rich formatting even though they weren't affected by the so-called security issues

yeah. by having an easy innaccessible solution you end up having that as the default for xmpp.

Yes it's possible to do both, but we it's not like we didn'T know at this point that almost all clients don't do both

the fact that 394 doesnt have any accessibility research behind it should be a blocker anyways

The issue isn't 394 or 0071 IMO. It's just that 393 makes client devs' lives easier at first glance and that's all they see. It only becomes painful if they start caring about all the corner cases, because then it's just not a battle that can be won this way.

> MSavoritias (fae,ve), accessibility is a UI topic, a XEP is wire format XEPs are proposals that also touch on client best practices, and in this case thats also whats happening, in addition to expressing support by way of a feature flag over the wire. and, regardless, the choice between xhtml and markup absolutely does involve UI/UX directly, seeing how end users would have to interface with these differently, by nature of markup being directly tied to the textual content. meanwhile, in the xhtml case, end users arent typically writing xhtml tags but clients have other ways of allowing this formatting from the UI side

i'll have to compare 393 with 394, i'm missing something else

>XEP-0394 was the replacement for 0071 ok now i see. yeah 0394 looks like nonsense and an even bigger nightmare to parse, but i understand why it may have been designed this way for backwards compatibility so that the plain text is a fallback

>Spans MUST NOT overlap with each other. >Spans MUST NOT overlap with the boundaries of a block-level markup element, but MAY be fully contained within a block-level markup element. >Block level markup elements MUST NOT overlap with each others boundaries. this seems to be more trouble than parsing xhtml and addressing 0071's concerns by allowing a subset of tags without security risks

>Entities MUST silently ignore elements and attributes (arbitrarly deep) in <markup/> which they do not understand; this allows for future extensions of the markup without breaking existing implementations. this is one of the perks of 0394 but also is no different from a theoretical rework of 0071, because unknown tags can simply be flowed as normal text (assuming those tags contain innertext)

>9. Security Considerations >REQUIRED. well, i can already put bounds checking as a consideration there, but im not an XEP author or editor as it stands

its funny that 0393 even mentions bounds checking though; either for 0393 or 0394 i think the general programmer would know the limitations of the implementation language for their client

bounds-checking isnt an XEP-worthy thing to note, that is

also lovetox will love this particularity of 0394, it seems to preserve the > prefixes in <bquote/> tags ;) i assumed 0393 was supposed to act the same way, where the original text was preserved but the formatting of said text was changed... as evidenced by *this*, _this_, and `this` preserving the delimiters

so i dont understand why >this is any different

i see the other mucs popping off right now, presumably about this

yep. the age old debate of xhtml :P

it's all a valid debate to have considering how 0071 fallback is implemented

drawbacks to every option we have :v

We're terafucked

> drawbacks to every option we have :v well yeah nobody said 0071 is good. but its the right direction and thats what we should be fixing imo

https://walla.rneetup.com:5281/file_share/daa7d2f4-f2a9-431f-9c88-1198cce343b1/d28a9971-a4a6-4b12-80ed-d91bdfabe7b4.png

counter is still displayed even tho chat is muted meme

sover

https://walla.rneetup.com:5281/file_share/a2938e8b-e580-4a28-b84f-6c6c7931381d/593df19e-e338-4014-b847-161586c6a8d4.png

Might it be reasonable that if we want gajim to not output verbose output when using -v when debug logging is enabled, that instead, gajim outputs a reminder message like "Debug logging enabled, not outputting verbose output to terminal", to prevent confusion. Also, having a reminder that we have debug logging enabled could be nice since it can be forgotten and it does a lot of writes which is bad for SSDs.

yeah umu, mute means no sound or notification

sover

so indicator stays

umu: what does "it's over"/"sover" mean to you? Is it like "That's game over for Gajim"?

nuh

No? What does it mean though?

It basically means nothing. It's a hyperbolic expression meaning something like "all hope is gone"

I see :D

umu: you seem to lose hope very often. Stay positiv 😄

he just suffers from 8chan brainrot

what

that's not even what it means

what is wrong with nickname changes??

context?

i see multiple participans within gajim when i change my own nickname

how are nicks so broken

multiple participants of... what exactly

.

nothing out of the ordinary here

not to say that changing nickname is flawless in MUCs, but it works generally as expected, i would hope

i dont think whatever youre experiencing should happen

omemo encrypted private channel

ohh

i havent tried that

it's a fucking mess

omemo itself doesnt break, no? are you just seeing ghost entries in the user list for old nicknames, or what

yes

gotcha

opal: I don't go on any chan

idk why you're trying to discredit me on here

i said it's over because I assumed the mute would be for the ticker for new messages to stop ticking

also I don't like you opal because I don't associate myself with pedophiles

very nice

> anime profile

> it's a fucking mess i'm gonna at least take back my frustration ↺

i'm sorry for swearing

my avatar isnt even remotely anime

Spam

nor do i give a damn about swearing

opal aka wowaname is a known pedo btw

fyi

there's a reason their xmpp instance is hosted in midolva

also bookmarks don't sync to gajim

> my avatar isnt even remotely anime not yours... ↺

ah ok i'll hide in my corner

bookmarks should sync

if you want to discredit me on my past behavior two can play at that game

Spam

opal: I get that it's easy to for a computer to accidentally store a picture of a 14 year old but actively possessing it without the intention of removing it from your system is in my views morally wrong

What does this conversation have to do with Gajim? I'm here to read about Gajim. Not to see personal wars. Can you have your war elsewhere please?

sorry

I'm just kind of upset that someone called me a 8chan user on this chat so I brought up some of their past behavior

I'll shh for now

Spam

opal, last warning, please refrain from attacking members of this chat personally

who was i attacking? i thought PMs were none of your business

so why now do you make them yours?

nor was i even attacking anyone in PM so regardless, wtf

warn the right person lovetox ✏

> he just suffers from 8chan brainrot

that was your message wasnt it?

yes and how is that an attack rather than an observation?

that clown dishes, surely he can take too

ban

gk i told you that you could ignore me rather than having the last word ✏

Spam

lovetox, do you just want me to leave now? because i get the impression that this muc is just a shitshow now

and i will have no part in a shitshow that continues like this

especially if you're going to "warn" me unsubstantiated

if you ask me to leave, i will, im not here for a fight

yes i would like you to leave, you seem often the center of whatever shitshow currently happens

maybe think about that

thats your fucking opinion but ok, as promised

Spam

Spam

mine too, by the way.

this is a pattern that spans across a number of mucs, I'm sure others have noticed

already gone, so lets leave it

There is a new Liberapay account for Gajim, if you like to support the project with a donation 💰️ https://gajim.org/#donations Support is always welcome, be it translations, bug reports, suggestions for improvement, or actual `code` 💡️

SerenityOS made a post that they started having issues on https://polar.sh/ where people can pay for things they would like to be fixed/made quicker. https://polar.sh/SerenityOS here is an example. Please bare in mind that I have JUST HAPPENED to see this post and I know nothing of polar.sh but it seems interesting or...? Well, I'm just sharing the webpage.

I don't know how they handle payments, etc.