jdev - 2025-05-03

> they usually dont need evidence at all to fuck you, and certainly will not need get data from your server Hard disagree. ↺

> moparisthebest: sure but your proposal would not hide it So password is not hidden either right. The world knows i use 123 to log in all along ↺

> although I don't see how you'd trust the server with information on what group chats you join and who you talk to but not with your blocklist Not neccesary all group are in bookmark which are we are looking to store indefinately. Metadata of dialouge are also not indefinate. ✏ ↺

I think not everyone want to publish their blocklist. it's better to have a xep to sync across devices spontaneously to provide end user an option when they don't want to publish their block list.

I also think blocking in itself is temporary act coz i believe bad actors are temporary. I hardly ever block anything outside of using fail2ban.

btw, https://xmppbl.org/ afaik are all hash

These are jids, which are User Accounts. It's understandable to not want to host a public repo of half of people's login Data.

You are comparing apples with oranges.

It's even probably illegal in europe

I've state my opinion on the matter: blocklist should be hashed when stored on the server. It's your software, do what you wish.

It is a list of hashes, read the spec https://xmpp.org/extensions/xep-0421.html

This would not even be illegal to host publicly, we do not, its stored in your privat data on your server, only you and probably law enforcement can access it.

roojid+occupant-id

+salt

and when it's a non-semi-anonymous, hash(roomjit+jid+salt)

Occupant I'd is always used not only in anonymous rooms

well then always hash(roomjid+occupantid+salt)

anyway, I'm gonna drop out of this topic for now coz there're other things to do. Thank you for the discussion.

Yeah you stated that before but brought no convincing arguments forth, so restating it adds nothing to the conversation

that's a subjective…

In XEP-0065, example 12[1] shows an entity refusing to negotiate a bytestream with an <error type="modify"/> element; shouldn't the type in this case be "cancel"? [1] https://xmpp.org/extensions/xep-0065.html#example-12

The implication of 'modify' is that a bytestream would be accepted if the parameters were correct, but in this case they are not; 'cancel' would mean don't even try again (but then why are you advertising support for something you are unwilling to support?)

It could be a "not with *you*" kind of deal, and the entity simply didn't exclude the feature in its service discovery response (it forgot or blocked the initiating entity after the fact) ✏

possible, and they could always request even in spite of the disco reply

but then a general iq error would be sufficient

<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>no means no</text>

In the <error/> element

Are "XEP-0503: Server-side spaces" implemeted somewhere?

Latest Cheogram Android has UI for some of it but incomplete

> Are "XEP-0503: Server-side spaces" implemeted somewhere? nicoco the author got some feedbacks and is planning to bump it ↺

I'm waiting server implementation