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
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.
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
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
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
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
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
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/mailm
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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.
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
legal, 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
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
27 matches
Mail list logo