[Standards] Re: Council (and what it does, and what it should do)

[Martin]

Quoting Goffi :
For the record, we'll have a meeting in Berlin next month (thanks to  
Debacle), to work exactly on that: interoperability issue with OMEMO  
(and A/V).


I like to add: It is an open sprint, so everybody is invited
to work on whatever they like :-) Please, everyone, register
yourself, if chances are ≥ 1 % that you come to Berlin:

https://wiki.xmpp.org/web/Sprints/2024-07_Berlin#Attendees

Cheers


___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Martin Dosch]

Dear all,

coincidentally I was implementing `tls-server-end-point` channel binding 
for go-sendxmpp this morning. As a client can choose the method to use I 
don't see an issue here.
I just prefer `tls-exporter` if TLSv1.3 is used and `tls-unique` 
otherwise and only use `tls-server-end-point` when it's the only method 
offered.
As Holger and Andrzej pointed out there might be cases where the better 
methods are not available and using a weaker one is still better than no 
channel binding at all.


Best regards,
Martin


signature.asc
Description: PGP signature
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Signing PubSub items (Proposed XMPP Extension: OpenPGP for XMPP Pubsub)

[Martin]

> Title: OpenPGP for XMPP Pubsub
[...]
> Specifies an OpenPGP for XMPP (XEP-0373) profile for the pubsub use
> case.
>
> URL: https://xmpp.org/extensions/inbox/pubsub-encryption.html

I hoped that the XEP would provide a way to sign blog posts or other
data, but it does not, at least not explicitely.

Use case: Help to prevent things like "Twitter: Fake Elon Musk scam
spreads after accounts hacked" on Libervia or Movim.

Is this out of scope?

Cheers

¹ https://www.bbc.com/news/technology-46097853 (2018-11-05)

(Reminder to myself: Fake Elon Musk on Libervia with his announcement,
he were up to buy Salut-à-toi. Sell my SàT shares, before people dare to
check the OpenPGP signature. Become rich.)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Clarify meaning of pubsub#item_expire: creation or modification?

[Martin]

On 2021-09-17 13:22, goffi wrote:
> there is no notion of "modification" in XEP-0060: an item with an
> existing ID is overwritten by a new item with same ID, not
> modified. The notion of modification has been introduced in XEP-0413
> (Order-By) that I've authored, because it's useful, but it's not part
> of XEP-0060.
>
> Thus, in the case of pubsub#item_expire, it can only reference the
> date of items creation (so if item A' with the same ID as item A is 
> published, it's the date of A' creation which is used, and A doesn't
> exist anymore).

Oh, I see. Thanks for the explanation! Then the patch might not be
necessary for XEP-0060. XEP-0413 does not mention expiration, which is
fine.

I still think, it might be useful to clarify the issue *somewhere*, just
to avoid any doubts.

Cheers
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Clarify meaning of pubsub#item_expire: creation or modification?

[Martin]

Hi,

this question came up when discussing the server side implementation of
pubsub#item_expire: Is expiry relative to original creation or to last
modification?

It looks like both options can make sense, but in most cases, last
modification is more useful, e.g. when a singleton node is updated or in
case of redacted blog posts.

Also, the standard already says, that re-publication were equivalent to
modification:

> Note: If a publisher publishes an item with an Item ID and the ItemID
> matches that of an existing item, the pubsub service MUST NOT fail the
> publication but instead MUST overwrite the existing item and generate
> a new event notification (i.e., re-publication is equivalent to
> modification).

To implement an absolute deadline of an item, the expiry time is not
useful anyway, because it is a per node option, not a per item one. In
such cases, the publisher should remove the node when time comes.

In any case, the standard should clear about what is intended.
Patch attached.

Cheers, Martin
diff --git a/xep-0060.xml b/xep-0060.xml
index 09638a6b..d5ea9ce7 100644
--- a/xep-0060.xml
+++ b/xep-0060.xml
@@ -3569,7 +3569,7 @@ And by opposing end them?
   10
 
 
+   label='Time after which to automatically purge items after last modification. `max` for no specific limit other than a server imposed maximum.'>
   604800
 
 10
 
 
+   label='Time after which to automatically purge items after last modification. `max` for no specific limit other than a server imposed maximum.'>
   604800
 
 
   
+ label='Number of seconds after which to automatically purge items after last modification. `max` for no specific limit other than a server imposed maximum.'/>
   
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Martin]

Quoting Kim Alvefur :

We were always at war with STARTTLS?


The world is at war with both ports < 443 and ports > 443.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP Modernization Roundtable Results

[Martin]

On 2021-06-22 16:51, Sam Whited wrote:
> * XEP-0138: Stream Compression, XEP-0229: Stream Compression with LZW
>   * MattJ: everyone is streaming video on mobile devices so XML 
> is not a big
>   resource hog that we need to worry about anymore

XML compression is probably not worthwhile for the IM use case and even
has privacy issues, but it might be very useful for IoT and similar
applications. Some without any privacy needs.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Announcing Slummit 2021

[Martin Dosch]

On 28.01.2021 09:28, Sam Whited wrote:

If we're streaming any of this for public consumption please let's also
stream it on YouTube. We need to meet people where they're at, and for
video streaming that's YouTube. We can of course do PeerTube too if
people want that, but most of the public are on YouTube.

—Sam


I agree on this. Afaik Jitsi-Meet is able to stream to YouTube so the 
people who are participating in the talk could join the Jitsi-Meet room 
and the audiance watch via YouTube.


In a recent training at my company we also had a good experience with 
muting all participants except the hosts and writing questions in the 
chat. One host who was not busy with the presentation was monitoring the 
chat, collecting questions and forwarding them to the presenter when it 
was suitable. Worked pretty good for us, maybe we could have a similar 
procedure with Jitsi-Meet, YouTube-Streaming and a MUC.


Best regards,
Martin


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0381 (Internet of Things Special Interest Group (IoT SIG))

[Martin]

On 2020-12-01 18:37, Jonas Schäfer wrote:
> 1) Do you think that the SIG is a good addition to the XMPP Community? If so, 
> why? If not, why not?

As a user of XMPP in IoT, I'm happy about a SIG working on the
relevant XEPs. And I'm thankful to flow and MattJ for managing
xmpp:i...@muc.xmpp.org?join

> 2) Would you join that SIG? If not, why not?

Yes.

> 3) Do you have any additional comments on that SIG, its mission or goals?

No.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0443 (XMPP Compliance Suites 2021)

[Martin Dosch]

Dear all,

I would like to also have XEP-0425: Message Moderation [1] added to the 
XMPP Compliance Suites 2021 as spam messages to MUCs are happening more 
often.


Would you consider adding it to advanced client and advanced server?

Best regards,
Martin

[1] https://xmpp.org/extensions/xep-0425.html


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0060: max #max_items

[Martin]

Quoting Tedd Sterr :
Alternatively, I presume 31 bits would be a safe* maximum positive  
integer value (max='2147483647').



* Limits are 'bad,' but I don't see anyone realistically needing 2  
billion entries, nor a server storing them.


Maybe in IoT use cases (sensor data) this limit can be hit in a
few years. I had PEP nodes configured to 2.7 million items (number
of seconds in one month) for that, only 800 times less. This was
only in a PoC project and we will use a much lower value in
production, but it is certainly not completely unrealistic.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management

[Martin]

On 2020-02-21 09:23, Daniel Gultsch wrote:
> Only someone who hasn't been on a German high speed train can say with
> confidence that desktop and web clients don't need stream management.

Yes, mobile ≠ Android/iOS! Many notebook computers are connected
to Wifi or "mobile internet" and used in public transport,
(over-) crowded places, or rural areas with flaky connections.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Simple JSON Messaging

[Martin]

On 2020-02-19 00:33, Dave Cridland wrote:
> It is normal, outside this group. That train has left the station, and
> there is little point in closing the stable door after the ship has sailed.

Correction: "The train has left the bike shed".

(Back to work, where we start to use XEP-0335: JSON Containers,
which seems to be sufficient for our simple use case.
Still, we thought about XEP-: CSV Containers.)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Reactions

[W. Martin Borgert]

Quoting Dave Cridland :

On Fri, 19 Jul 2019 at 15:52, Georg Lukas  wrote:

4. Limitation to Emoji

...

Loose agreement here, but also, I suspect people will rapidly want to react
in custom ways not expressible in Unicode, so we might want URls or inline
media to be possible too.



We already see, the emojis get less important here and there and are
replaced by "stickers".
Which is already supported in XMPP by XEP-0231 (bits of binary, BoB).
This allows even more childish and silly reactions!
XMPP reactions should support that.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-03-31

[W. Martin Borgert]

Quoting Dave Cridland :

* But this is creating our own cryptography, and the XSF should not be
doing that.


If I understand ATT correctly, it's not cryptography in itself, but
automation of key "trust state" copying. More a kind of convenience
function. Please CMIIW.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[W. Martin Borgert]

Quoting Sam Whited :

IM isn't the web,


I agree. IM messages are - in general - short. Named URLs allow
shorter messages, that are better readable esp. by non-technical
people. In the context of 0393, I suggest something like:

[http://shakespeare.mit.edu/macbeth/ The Tragedy of Macbeth]

and

[xmpp:x...@chat.yax.im?join Off-topic MUC]

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[W. Martin Borgert]

Quoting Sam Whited :

What is the use case for hyper links and who does it benefit? I
keep hearing people say they want them, but I don't really
understand why they're necessary over just auto linking things that
look like URLs. Thanks.


URLs are sometimes readable to me, sometimes not.
For most non-geek people URLs are never readable.
Therefore, HTML has an anchor element with content and
not just auto linking. Mainly an aesthetical question.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] One true final way to mark up messages

[W. Martin Borgert]

Quoting Ненахов Андрей :

XHTML is deprecated,


This, unfortunately, is the case. I'm not completely
convinced of the arguements against 0071.


and all other proposals are not in usable shape.


0393 is not bad, IMHO. It might need two or three additions,
esp. hyperlinks, but most typical use cases are covered.

For anything more complex there is 0071. It only needs to be
resurrected. Like Lazarus.

Cheers

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0335 (JSON Containers)

[W. Martin Borgert]

On 2019-02-04 19:17, Jonas Schäfer wrote:
> 5. Is the specification accurate and clearly written?

Minor clarification would be nice:

It was not immediately clear to me, that the json element must
contain exactly one JSON object. And that for multiple JSON
objects one must either use multiple json elements in a row or
construct a JSON object containing others.

Cheers
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Best practices for GDPR compliant deployment of XMPP

[W. Martin Borgert]

On 2018-05-25 09:13, Winfried Tilanus wrote:
> Beside that informative XEP, I (or a group of people willing to do so)
> publish an own document discussing XMPP & the GDPR in detail.

Having XEPs explaining best practices for

 - retrieving all data belonging to one user
 - removing all data of a particular user
 - agreeing to terms of service and withdrawing again
 - etc.

is certainly needed by many people in an outside the EU.
It is not necessary to even mention GDPR in those XEPs.

Informal documents (even blogs) could then link the XEPs to GDPR
or other, similar laws.

Just my 2€¢.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[W. Martin Borgert]

On 2018-05-13 13:05, W. Martin Borgert wrote:
> I would prefer
>
> 
> ...
> 
>
> Everybody can just us the attribute or ignore it.
   ^e
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[W. Martin Borgert]

On 2018-05-13 12:38, Jonas Wielicki wrote:
> On Samstag, 12. Mai 2018 19:55:52 CEST Paul Schaub wrote:
> > 
> > 
> > This is an ephemeral message
> > 
> > 
> 
> This is awful. It will require the message to carry a non-empty  to 
> deal with the MAM/Carbons mess (and also to help users of clients which do 
> not 
> support this feature).

I would prefer


...


Everybody can just us the attribute or ignore it.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[W. Martin Borgert]

Quoting Alexander Krotov :

Disappearing messages without end-to-end encryption and forward
secrecy are useless at best. They give the user false sense of
security. That is why Telegram implements timers for "secret" chats
only I believe, as I said in the first message.


I respectfully disagree.

Timers (or "ephemeral messages") are not a security feature, but only
a means of data hygiene.

Therefore it is orthogonal to any encryption and it does also not
matter, whether your peer or one of your peers devices or resources
does implement the feature or not. No need to check. As sender, just
use the timers and let the problem of deleting messages to the
recipient.

Cheers

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[W. Martin Borgert]

On 2018-05-10 14:31, VanitasVitae wrote:
> I'd also rather not tie it to OMEMO. The same principle of disappearing 
> messages could also be applied with other crypto in mind, or even no crypto 
> at all. Remember, this functionality is not designed to give you any 
> (serious) security improvements. Its rather a function which teenagers find 
> neat and which was implemented in Signal for some reason.

D'accord with not coupling ephemeral messages to encryption.
I would find it especially practical for unimportant messages with friends.
We just don't want all the nonsense cluttering our archives.
No need to check other sides client for that feature, of course.
It's their problem if they really like to store the noise.

Cheers
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

[W. Martin Borgert]

Quoting Matthew Wild :

The whole point of the autojoin logic was to keep clients
synchronised. Either we want clients in sync or we don't. And I think
we do.


Sometimes yes, sometimes no.

I would like to have some rooms autojoined when I'm at home, but not
when at work. And vice versa.

(I'm using different accounts for work and private stuff, but maybe
not everyone uses multiple accounts.)

Still, between the options "always synced" and "never synced", I
prefer the former.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0394: too weak to replace XEP-0071

[W. Martin Borgert]

Quoting Jonas Wielicki :

If you are doing graphics/text design/publishing with your IM client, you’re
doing it wrong, in my opinion.


But XMPP is not only IM. What about blogging or social networks like
Movim or Salut à Toi or before Jappix, which present a rich web
interface? No need for specific fonts or colours, I agree, but people
want probably a little bit more output control then in the IM world.

Cheers

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

[W. Martin Borgert]

Quoting Kozlov Konstantin :

The problem of XEP-0393 is that markup mixed with plain text and it's hard
to purge it from it.


That's why I prefer Markdown (or RST, it's almost the same):
It is more or less readable as plain text to most of us.

Cheers

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [STANDARDS] XEP-0394: too weak to replace XEP-0071

[W. Martin Borgert]

On 2018-03-15 10:22, Kozlov Konstantin wrote:
> I don't want to discuss XEP-0393, 'cause the whole idea of using LML in IM
> sounds bad. Flaws if it is obvious, so it's needless to mention them again.

I disagree. Yes it is ugly, but having a widely used LML, such
as Markdown (in contrast to some strange homebrew) in XMPP would
be a pragmatic approach, IMVHO.

Many people know Markdown syntax nowadays, there are parsers for
it in many different programming languages, and we already know
how ugly and illogical it is. Just needs a new XEP :~)

> According to my UX, XEP-0071 functionality mostly used for:

I agree with all your points.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] [OT] Meetup in Berlin on Friday

[W. Martin Borgert]

On 2018-03-12 23:08, Holger Weiß wrote:
> If you'd like to talk to us, you can join our MUC room:
>
>   berlin-mee...@conference.conversations.im

And we even have a pubsub node you can subscribe to:

https://de.movim.eu/?node/pubsub.movim.eu/berlin-xmpp-meetup
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0283 Moved - Security and Usability

[W. Martin Borgert]

Quoting Georg Lukas :

b) have a tool that will perform "account migration", i.e. you enter the
credentials to your old account and to your new account and the tool
will automatically move all your contacts from A to B.


Only contacts or as much of personal data as possible?
What about bookmarks? Or anything that is in PEP?
That would be very useful.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] 0174 Serverless Messaging: Discovering Capabilities

[W. Martin Borgert]

Quoting Peter Saint-Andre :

Well, it worked OK at small conferences when universal connectivity
wasn't so common in the pre-smartphone days (folks had a lot of fun
using it in Adium and iChat back then), but I haven't seen it used since
2010 or so.

It went to Draft and Final quickly (perhaps we were more efficient about
moving things forward back then), but it doesn't seem relevant anymore.


I didn't use this feature for some years, but I can imagine, that
it might be a relevant niche. Having a protocol that can survive
certain desasters like "no mobile internet available" still sounds
interesting and worthwhile to me. Might even be interesting in the
field of humanitarian aid or when privacy is more relevant.

Cheers

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Adding logo to MUC and PubSub node

[W. Martin Borgert]

Quoting Jonas Wielicki <jo...@wielicki.name>:

On Donnerstag, 8. Februar 2018 14:34:12 CET W. Martin Borgert wrote:

I had another idea before coming up with the configuration variable,
but I find it very ugly, but maybe others might find some beauty
(or pragmatism) in it:

A PubSub node could have a "magic" node


We need to get this terminology straight. When you say "PubSub node", do you
in fact mean a pubsub node (i.e. a specific @node value on a specific pubsub
service with JID X) or a PubSub service with JID X?


I hope to get the terminology right this time:
A PubSub node could have a "magic" item.
A PubSub service could have a "magic" node.
Does this make sense?

For e.g. Movim both a logo for service and for a node seems to be
useful.


I think specifying avatars for each PubSub *node* could be tricky. For
services (which I assume you meant) see below.


If there were a "magic" item on a node, it never must be removed
automatically, but only on user request, right?


The "magic id" (again, only for PubSub services, not for individual nodes) is
obvious, I’d simply use the same the XEP-0084 uses. That could even work
magically with client code.


Nice!

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Adding logo to MUC and PubSub node

[W. Martin Borgert]

Quoting Daniel Gultsch :

polling is a terrible idea traffic wise and very nontransparent for the user.

I don't have an opinion on pubsub.


I had another idea before coming up with the configuration variable,
but I find it very ugly, but maybe others might find some beauty
(or pragmatism) in it:

A PubSub node could have a "magic" node, i.e. with the magic id
"pubsub_logo". This node contains the logo, it can be upgraded and
notification to users would be immediate. But a "magic id"? Like
"favicon.ico"?

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Adding logo to MUC and PubSub node

[W. Martin Borgert]

Quoting Timothée Jaussoin :
In the end I don't think that it's a big issue to have those info  
requested manually, having a cache of a few hours on the clients is

an OK solution for me at the moment.


Maybe a refresh or poll rate of e.g. 12..24 hours can "officially"
be suggested? Not really nice, but better than not having logos or
invent something complicated that will never be implemented...

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Adding logo to MUC and PubSub node

[W. Martin Borgert]

Hi,

this is an idea mainly for the "social network" aspect of XMPP:
A logo for a MUC or for a PubSub node, similar to a user avatar.

Such a logo, emblem, or symbol can be a good indicator for users
to find the right MUC or PubSub node in a social network
application or graphical XMPP client.

How about introducing two configuration variables, one in
https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owneronfig:

var='muc#muc_logo'

And the second one in
https://xmpp.org/extensions/xep-0060.html#owner-configure:

var='pubsub#node_logo'

The value should be a  element from
https://xmpp.org/extensions/xep-0221.html.

IMHO, the value should be restricted to
 1. images, or would a sound make sense? Maybe...
 2. inline data, so that a link to a web resource cannot be
abused for snitching IP addresses

What do you think?

TIA & Cheers
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Expected behavior when blocking all unknown JIDs

[W. Martin Borgert]

Quoting Goffi :

Instead of blocking unconditionally unknown users (which is not an option for
me), would not it make sense to use some kind of challenge (e.g. captcha or
computational challenge) ? This would not block everything, but probably a
good amount of SPAM/SPIM.


For email, there is greylisting. IIRC, the receiving server says
"try again later" on the first contact. This will be done by any
legitimate server, but for spammers holding the message for e.g.
one hour is too expensive. Any further messages will be delivered
immediately. Neither sender nor receiver notice anything, only a
one hour delay of the first message. In my experience, this
method doesn't prevent all email spam, but a large part of it.

Would this SMTP error 450/451 be applicable to XMPP?

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] 33C3 talk on Signal and current XMPP issue in providing a similar UX

[W. Martin Borgert]

On 2016-12-29 23:32, Tobias Markmann wrote:
> After
> registration, they need to easily/secure/privacy-enforcing fill up their
> roster with contacts based on known contact information like phone number
> or e-mail address.

I suggest to popularise the idea of identical email and XMPP
address. While this is, of course, optional, it makes contact
matching even more easy than with phone numbers.

As long as 98.7% of the planets email population happen to use
the same provider and this very provider dropped XMPP support,
it is, unfortunately, difficult to achieve.

Btw: You can reach me as {mailto,xmpp}:deba...@debian.org :~)

Btw': Thanks for your notes, Tobias!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] "Self-destruct" message timeout deletion hints

[W. Martin Borgert]

Quoting Dave Cridland :

That's not the case in an open ecosystem -
someone's client could just ignore the request, and might even have a
setting to do so.


It is very probable that many clients will offer this setting, so users
will be rapidly aware of it - and that their peer has it, too!

The question is: Should this be a "convenience" feature or a
"security" feature. I see it as the former, and that way it is fine.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[W. Martin Borgert]

Pardon, this was meant to sent privately :~) Usability issue in Horde,
I assume, or lack-of-brain problem between keyboard and chair.

Here in English: Germany and probably other countries like to make
anonymous SIMs illegal. Relying on phone numbers would make anonymous
"Easy XMPP" illegal, too, which is probably not a goal.

And: What is XEP-PARS?

TIA!

Quoting "W. Martin Borgert" <deba...@debian.org>:


Hi,

eine private Bemerkung und eine Frage:

Quoting Georg Lukas <ge...@op-co.de>:

2. Use of phone numbers: unfortunately this is an unsolved problem yet.


Da demnächst anonyme SIM-Karten in Deutschland (und vermutlich auch
anderen Staaten) outlawed werden - egal wie erfolgversprechend man
das einschätzt - wäre mit Telephonnummern als Id auch anonymes
"Easy-XMPP" illegal. Das kann das Ziel nicht sein.


- XEP-PARS: creation and full handling of links with preauth element


Was ist das für ein XEP? Hast Du einen Link für mich? Danke!

Cheers

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___




___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[W. Martin Borgert]

Hi,

eine private Bemerkung und eine Frage:

Quoting Georg Lukas :

2. Use of phone numbers: unfortunately this is an unsolved problem yet.


Da demnächst anonyme SIM-Karten in Deutschland (und vermutlich auch
anderen Staaten) outlawed werden - egal wie erfolgversprechend man
das einschätzt - wäre mit Telephonnummern als Id auch anonymes
"Easy-XMPP" illegal. Das kann das Ziel nicht sein.


 - XEP-PARS: creation and full handling of links with preauth element


Was ist das für ein XEP? Hast Du einen Link für mich? Danke!

Cheers

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0115 Entity Capabilities - clarifications

[Martin Morrison]

Alban Crequy wrote:

Le Sun, 15 Aug 2010 23:05:49 +0100,
Martin Morrison martin.morri...@gmail.com a écrit :


I've recently been implementing XEP-0115 Entity Capabilities, both the
latest and the legacy versions, and have a few issues that I feel
should be clarified in the latest version of the spec:

1. The legacy version of the spec explicitly says (in 4.2, below
example 8):

[...]


2. The spec only uses the word SHOULD when specifying how the Disco
'node' attribute is formed. A receiving entity that supports both
Entity Capabilities and has multiple disco#items nodes thus has
somewhat of a dilemma in deciding how to respond to a disco#info
request for an unknown node. Should it return an item-not-found/
error, or assume that the remote entity has used some other mechanism
to construct the 'node' attribute in the request, and return the base
capabilities as if the node was empty?


I think item-not-found/ is best: sending an empty capability in this
case is bad because the hash will not match and the client will discard
the reply.


This assumes that the receiving entity re-extracts the hash from the 
node on reply. If I write a client that chooses to generate uuids for 
the node attribute, then I am fully compliant with XEP-0115, but your 
client will never tell me your capabilities.


If what you've suggested is the recommended behaviour, shouldn't the 
specification use MUST when specifying node#hash as the value of the 
'node' attribute?



3. Related to item 2, the following race condition can occur:

- ro...@shakespeare.lit sends Presence to jul...@shakespeare.lit with
an Entity Capabilities hash
- In response, juliet sends a disco#info request with the node#hash
as the 'node' attribute
- Meanwhile, romeo changes the feature set of his client (e.g. turns
on his camera)
- Upon receiving the disco#info request, what does romeo do?

As the 'node' attribute has been formed using the recommended method,
Romeo can establish that the hash doesn't match his current
capabilities. Should he return an error, or ignore the contents of the
'node' attribute completely and just return his current capabilities
(which will be accepted, since he will already have pushed an updated
hash via Presence)? Either way, I think it would help if the spec
specified what was expected.


For this race, it was suggested to just send item-not-found/ in this
thread: http://mail.jabber.org/pipermail/standards/2008-May/018713.html

Sending item-not-found/ will work: Juliet will receive the new hash
a bit later and she will send a new disco request with the new hash.

Alternatively, Telepathy-Gabble keeps a cache mapping
hash-capabilities. So with this implementation, Romeo will send the
*previous* capabilities corresponding with the requested hash. Juliet
will ask the capabilities again anyway when she receives the new hash
if she wants to know the new capabilities.


This requires Romeo to keep track of the hashes of every combination of 
capabilities he has every published. It also doesn't sit well IMO with 
the existence of multiple hashing algorithms - the node#hash 'node' 
attribute doesn't tell you what the hashing algorithm is, making it even 
harder to know what capabilities to return (albeit on the very unlikely 
off-chance that two different capabilities hash to the same string under 
two different supported algorithms).



Disco queries in XEP-0115 are not what are your current caps? but
what are the caps corresponding to this hash?. It is up to the
clients to keep track of hashes and to make new disco requests when
they receive a new hash if they want to know the capabilities.


If they really are, as you say, what are the caps corresponding to this 
hash? then shouldn't the request mirror that, by explicitly specifying 
the hash algorithm and hash string? Currently the request on-the-wire 
would be interpreted as what are the caps of the node known as 
'node#hash'?, with nothing to differentiate this from a plain XEP-0030 
request.


I agree with the sentiments of your points, but the current 
specification feels like its trying to pander to the legacy format too 
much, resulting in multiple ambiguities overall.


Cheers,
Martin


Alban

[Standards] XEP-0115 Entity Capabilities - clarifications

[Martin Morrison]

I've recently been implementing XEP-0115 Entity Capabilities, both the
latest and the legacy versions, and have a few issues that I feel
should be clarified in the latest version of the spec:

1. The legacy version of the spec explicitly says (in 4.2, below example 8):

Note: The set of features that a given entity advertises in response
to a client#version request and all client#extension requests MUST
be equivalent to the response it gives to a disco#info request with no
'node' attribute.

The latest revision of the spec does not have a similar clause (for
client#hash == no 'node'). I assume this what is intended though,
and feel it could do with being made explicit.

2. The spec only uses the word SHOULD when specifying how the Disco
'node' attribute is formed. A receiving entity that supports both
Entity Capabilities and has multiple disco#items nodes thus has
somewhat of a dilemma in deciding how to respond to a disco#info
request for an unknown node. Should it return an item-not-found/
error, or assume that the remote entity has used some other mechanism
to construct the 'node' attribute in the request, and return the base
capabilities as if the node was empty?

3. Related to item 2, the following race condition can occur:

- ro...@shakespeare.lit sends Presence to jul...@shakespeare.lit with
an Entity Capabilities hash
- In response, juliet sends a disco#info request with the node#hash
as the 'node' attribute
- Meanwhile, romeo changes the feature set of his client (e.g. turns
on his camera)
- Upon receiving the disco#info request, what does romeo do?

As the 'node' attribute has been formed using the recommended method,
Romeo can establish that the hash doesn't match his current
capabilities. Should he return an error, or ignore the contents of the
'node' attribute completely and just return his current capabilities
(which will be accepted, since he will already have pushed an updated
hash via Presence)? Either way, I think it would help if the spec
specified what was expected.


Cheers,
Martin