Hi Melvin,
I'll give a comment from my perspective, not representing the whole
Council:
On Sat, 2024-08-31 at 12:00 +0200, Melvin Keskin wrote:
> 1. What exactly do you mean by *The language is weird*?
I'm not sure who said this, but this sentence for me sounds overly
complicated: "In addition t
So, to summarize these tables:
- on-reconnect and on-update are exactly the same, completely ignore
`autojoin` and only look at `joined`. If it's set, join, if not, leave
(where obviously it's not possible to leave when not joined or join
when already joined)
- on-login completely ignore `joined` a
Hi,
On Tue, 2024-08-27 at 14:18 +, Tedd Sterr wrote:
> Would anything break if a 'joined' attribute were added? Then we
> could gradually migrate to using that, and autojoin regains its
> actual purpose.
Well, let's play the scenario where we had `autojoin` and `joined`
independent. What is t
Hi,
I think all of these discussions are merely caused by wording of the
attribute. For historical reasons, it's called `autojoin`, but what we
nowadays want to say with it (or how most clients want it to be used)
is `joined`. Maybe we want to add a note to the XEP that explains this?
The concept
Hi,
Thanks for proposing this specification.
I still fail to see why it is necessary or a good idea to create a new
Jingle session for every participant stream. I see a lot of downsides
without any obvious upside. As I understood, the reason to do this is
that some SFU implementations use one Web
Hi Philipp,
I'm not the author, but I feel I can answer most of the questions.
On Sat, 2024-06-29 at 13:25 +, Philipp Hörist wrote:
> Im not getting the difference between and .
> And the XEP makes no attempt to describe it.
Quick responses are regular messages with a . They are only
availa
Hi,
It's a great starting point. As additional input, here's a screenshot
from the notification settings screen in Slack:
https://imgur.com/i6O8GNO
It's probably on the upper end of features one could possibly need, but
I personally do enjoy having the different option for mobile devices.
Marvin
Hi,
On Tue, 2024-06-04 at 08:43 -0500, Stephen Paul Weber wrote:
> Implementors should be aware this is
> experimental and may change and be flexible to support multiple
> versions of
> it over time, etc.
I think my point is that I don't have the feeling that this the case.
With my developer ha
Hi Goffi,
Thanks for your message.
I know I'm not particularly good with words and my language sometimes
tends to be perceived as aggressive or exclusive. I did not intend to
attack or insult anyone and I apologize if I did.
On Tue, 2024-06-04 at 14:52 +0200, Goffi wrote:
> Though I usually appr
Hi,
On Tue, 2024-06-04 at 11:10 +0200, Maxime Buquet wrote:
> No, this only says that this is a much needed feature, whether or not
> the
> protocol is considered "ready for use in production software"
> (whatever that
> means[0]) is irrelevant IMO.
Of course there are three kinds:
(a) Those that
On Mon, 2024-06-03 at 18:29 +0300, MSavoritias wrote:
> Agreed. We don't need yet more XEP numbers to shift through. We
> already
> have way too many of them.
> Instead we should start using the namespaces more. And also we
> shouldnt
> be afraid to update Stable XEPs if there are substaincial chan
Hi,
On Mon, 2024-06-03 at 14:10 +0200, Goffi wrote:
> Experimental is for the specification. Adding whatever status or
> workflow change
> you want will not prevent developers from implementing whatever they
> feel is
> relevant. People have been implementing things that were not official
> XEPs
Hi,
On Mon, 2024-06-03 at 11:02 +0200, Goffi wrote:
> I completely agree with this. I don't think that creating another
> status or
> location for proto-proto-XEPs would be beneficial, as it would only
> add more
> confusion. We already have /inbox for this purpose.
The purpose of inbox is to a
Hi,
On Sun, 2024-06-02 at 20:30 +0200, Florian Schmaus wrote:
> Therefore, I suggest that the XSF embraces competition in the early
> stages and, in case of duplicated efforts, limits itself to
> advocating
> certain extensions.
I generally agree.
However there has been cases, where a ProtoXEP
On Wed, 2024-05-29 at 08:57 -0500, Stephen Paul Weber wrote:
>
> I disagree. I think it is a chatroom.
A user is not a chatroom. A chatroom is something where users join and
leave and send messages to that are received by other currently joined
users in the room.
I have never heard of someone s
On Wed, 2024-05-29 at 13:02 +, Stephen Paul Weber wrote:
>
> A 1:1 chat *is* a groupchat with two participants. It's not a MUC but
> as you
> quoted the XEP says it doesn't have to be.
The XEP says that clients can assume it is MUC, but that it doesn't
have to be.
It has to be a "chatroom o
On Wed, 2024-05-29 at 11:32 +, Stephen Paul Weber wrote:
> > For MUCs, it is a perfect fit for XEP-0402: PEP Native Bookmarks
> > , in the spirit of XEP-0469: Bookmark Pinning? eg:
>
> For MUCs or for any other chat with more than one person inside,
> which
> includes 1:1 chat. Bookmarks2 sa
Hi Goffi,
Before going on your specific points, I'd like to make clear that I'm
all in favor of this happening and this vote was very uneasy to me,
because I also don't want to discourage you. I still do think that this
XEP is bad for many reasons, some of which I apparently fail to get
across, so
Hi Goffi,
On Tue, 2024-05-21 at 18:04 +0200, Goffi wrote:
> Could you please tell me more about this use case and why it isn't
> covered by
> Jingle transmission? Specifically, what is the advantage of sending
>
> through the server instead of handling it directly? I'd like to
> understand
> y
Hi Goffi,
On Tue, 2024-05-21 at 12:47 +0200, Goffi wrote:
> I know that, I've just ruled out using through the server
> as it has
> been proposed in another feedback.
Why do you rule that out? Because you don't see a purpose, when my
whole point is that I do see a purpose? Of course I can send
Hi Goffi,
See inline comments. Sorry for the wall of text and if it overlaps with
one of the mails you wrote since I started writing this.
On Mon, 2024-05-20 at 16:51 +0200, Goffi wrote:
> There are many benefits to using CBOR:
>
> - It is smaller. While individual pieces of data may be tiny, th
Hi,
I also am not sure why to do this custom-CBOR-via-Jingle approach.
- I don't see a good reason to use CBOR instead of JSON or XML. We're
just adding another object encoding scheme to the protocol suite
without any obvious reason.
- If we define a protocol for remote control, I would prefer thi
le to implement tls-server-end-point even if tls-exporter is
more secure), but those shouldn't be normative in any capacity.
Marvin
On Wed, 2024-05-08 at 16:42 +0200, Florian Schmaus wrote:
> On 08/05/2024 12.41, Marvin W wrote:> To address your concerns I'd
> suggest the follo
gt; any
> way, and if there's a bad thing that defeats the entire purpose of
> the
> XEP and is likely to happen, it seems worth calling out.
>
> —Sam
>
> On 2024-05-08 10:29, Marvin W wrote:
> > On Wed, 2024-05-08 at 10:19 -0400, Sam Whited wrote:
> >
On Wed, 2024-05-08 at 10:19 -0400, Sam Whited wrote:
> I'd like to see the security considerations expanded on this.
>
> In particular, in the business rules it mentions the fact that if
> occupant-id isn't supported it could be spoofed. This should exist in
> the security considerations.
Fair.
Hi Travis,
While I agree with most of your assessment in general, there is a few
things that need to be corrected:
Key pinning using '487 would not have prevented the jabber.ru attack,
as it is already known that the attacker was able to intercept and
handle http(s) requests themselves, so they w
Hi,
This XEP has two parts:
1. An IQ-based protocol to request a meeting link from a server.
2. An additional element to add to a message to send the meeting link
to another party
The second feature is already available via XEP-0482, which describes
call invites using Jingle and external URIs. Th
On Sat, 2023-02-25 at 11:35 +0100, Florian Schmaus wrote:
> What I tried to express is that changing the semantics of the RFC
> 'id'
> attribute in a new RFC is not a viable solution. Simply because you
> still need to operate with older implementations that do not follow
> the
> newer RFC. Henc
On Sat, 2023-02-25 at 10:50 +0100, Florian Schmaus wrote:
> However, it is still unclear to me how changing the RFC 'id'
> attribute
> specification from "must be unique within the scope of the stream id"
> to
> "must be globally unique, for example by using UUID" solves much we
> discussed in t
On Sat, 2023-02-25 at 10:39 +0100, Florian Schmaus wrote:
> As I wrote before, if, for example, the recipient's server also
> stores
> groupchat messages in the user's archive, then the recipient will
> receive a groupchat message containing (at least) two stanza-id
> elements:
> - one added by t
I generally like the idea of the MUC assigning the id to it's outgoing
messages instead of using the id proposed by the occupant sending the
message.
I also think that if we all agreed that we want that, we could migrate
to that situation in a backwards-compatible manner: the #stable-id
feature, a
On Wed, 2023-02-22 at 19:02 +0100, Florian Schmaus wrote:
> That is where we already think different. The more archives messages
> are
> contained in, the higher the chances are that they are preserved and
> recoverable. Which is usually a good thing.
The ground truth for messages received by th
Hi Flow,
As it stands today, every message ideally has no more than two IDs:
- The sender assigned id (origin-id or message's id-attribute) which is
required so that senders can be assured that the message is the one
they sent when they fetch them from the archive or get reflected from
MUCs, recei
Hi,
This is feedback for the latest PR to XEP-0359.
> The value of origin-id is spoofable and hence MUST not be used when
referencing other stanzas.
- This doesn't explain at all what "spoofable" means.
- origin-id's are supposed to be unique only within the scope of the
origin. In semi-anonymou
I think we came up with the common understanding that to reference a
previous message in a conversation, we use
- the origin-id or message id in direct chats
- the MUC service's stanza-id in MUCs + some kind of method (e.g.
presence tracking, occupant-id) to have certainty that the sender is
the sa
For completeness also here: ACK. (I see you already noticed my ACK on
GitHub).
Marvin
On Mon, 2023-01-09 at 10:11 +, Kevin Smith wrote:
> Natalie, Marvin,
>
> https://github.com/xsf/xeps/pull/1261 has been submitted to add a
> schema
> - are you ok with the change?
>
> /K
> ___
I guess it wasn't obvious what I was referring to here. Of course it's
totally fine to ask initiators to create an identifier that they
consder globally unique, but recipients can never rely on that. And as
such a MUST statement doesn't make sense. The reason is that as soon as
a "globally unique"
Hi,
1. It is impossible to guarantee that an identifier is "globally
unique", thus this requirement should not end up in any specification.
2. The session ID is already required to be random as per XEP-0166.
What is the problem that you want to solve here? Looking at the
protocol, the only thing
I also agree that a recommendation to use UUID is totally sufficient
here (call it RECOMMENDED or SHOULD, I don't care). There is no need to
require a UUID. Adding a recommendation for UUID is also inherently
backwards compatible and therefor does not require a namespace bump.
I also doubt the nec
Hi Thilo,
On Wed, 2022-10-19 at 21:41 +0200, Thilo Molitor wrote:
> I want us to move away from that "PLAIN is sometimes needed, let's
> support
> it in all relevant clients without further interaction by the user
> and ignore
> any security implications this might have" stance that seems be
> c
I think the specification partially exaggerates on what it is able to
actually achieve security-wise.
The requirements say: "Allow detection of SASL mechanism downgrades
even if no channel-binding is in use.". However, as this is an
extension to SCRAM, it only allows detection of SASL machanism
do
Hi Goffi,
Some feedback for the proposal:
I don't really like the design to put a reference to another node's item into
the NodeID of the attachment node. XEP-0060§12.14 seems to discourage such
hierarchy semantics in the NodeID and suggests using XEP-0248 instead, although
this probably doesn'
Hi,
[ I already sent this to jdev mailing list but someone told me that many
interested folks are not actually subscribed to that list, so I'm resending it
to standards mailing list. ]
FrOSCon is a yearly two-day conference at the Bonn-Rhein-Sieg University of
Applied Sciences near Cologne, Ger
There are different types of XEPs as outlined in XEP-0001:
https://xmpp.org/extensions/xep-0001.html#types
You are talking about Standards Track XEPs which, as the name suggests, define
the standard for the protocol ("protocol extensions") and thus are typically
rather technical.
This is a Proce
Hi,
On 09.01.22 21:50, Dave Cridland wrote:
> I'd still argue that it's a bad idea these days, even if Matrix haven't
> learned from the trouble it's caused in email. Most other proprietary
> messaging apps just have one form, the only reason email (and us, and
> Matrix) went for alternatives is b
Hi,
On 09.01.22 13:24, Dave Cridland wrote:
> I'm astonished you can simultaneously argue that XEP-428 should have
> added this functionality *and* the functionality has no overlap. Surely
> it must be one or the other, and not both?
After I proposed this and you argued against, I understood your
Hi,
On 08.01.22 23:34, Dave Cridland wrote:
> In this case, you've got a pre-existing fallback extension that you
> *could* - and indeed *have* - proposed extending in exactly this way
> without any problem, but for some reason you've decided to make an
> entirely new one instead of continuing tha
On 07.01.22 09:04, Thilo Molitor wrote:
> Why an extra XEP instead of extending XEP-0353 to include group calls?
> I recently reworked the whole XEP-0353 and given that this includes a
> namespace bump, it would be easy to extend it to include other invite types
> alongside the jingle invites alr
Hi,
On 15.12.21 17:24, Florian Schmaus wrote:
> The receiving entity of an incomplete submission form SHOULD only
> process (e.g., apply) the submitted field
I don't think that description really works well in the general case.
What does it mean to not "process" a non-submitted field? In many case
Hi,
Answering the standard questions first.
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes.
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
No.
The introduction explains different
On 03.07.21 20:35, JC Brand wrote:
> If you're behind a corporate firewall, [...]
I was rather thinking of company internal servers that are only
reachable from within the local network.
> Given that users already share URLs, I would like to have better
> metadata so that I can provide a better U
Hi,
XEP-0447 currently lacks a content-disposition information to clarify if
a (media) file should be displayed inline or not. This is on my TODO.
XEP-0447 does not allow for mixed content which XEP-0385 supports.
Including the hash is already "only" RECOMMENDED for XEP-0447. However
it is requi
Hi,
Remember that URLs are not guaranteed to be globally reachable
(examples: restricted to company network or requiring authentication).
For most users it's not easily understandable if a URL can be reached by
the recipient client or not. Thus sending an URL of funnypics.com
instead of downloadin
Hi Alexander,
Each sticker in a pack can be uniquely identified by the hash of the
image file in the element. As is described in XEP-0447,
the file hash can also be used for caching, even if you don't fetch the
full sticker pack (or don't support XEP-0449 at all).
Marvin
On 07.05.21 16:48, Alex
Hi,
> wss://:5443/ws
> ws://:5443/ws
> wss:///ws
> ws:///ws
- ws://...:5443/ws makes no sense. Port 5443 is obviously a reference to
HTTPS 443 port which is TLS encrypted, so you shouldn't make non-TLS
connections to 5443. If any, use something like port 5080 or 5280.
- While technically you coul
Hi,
On 23.12.20 17:47, Philipp Hörist wrote:
> and when would a client add this notify tag? Should the client let
> the user decide? (I dont like that) Is there any reason why i would
> not add to every message? I see no downside for the sender
Client should only add the tag on user request (
Hi there,
I actually was working on something with partially overlapping goals,
that is
a) being notified for relevant groupchat messages via push
notifications. This is mostly relevant for iOS push notifications (at
least as far as I understood during last summit).
b) signal to recipient that a m
Hi,
On 09.12.20 08:59, Florian Schmaus wrote:
> But the recipient would be able to apply the same rules regarding
> localization as the sender when counting grapheme clusters.
Which rules? Unicode does not provide a locale specific grapheme
clustering algorithm, TR29 only mentions that those exis
Hi,
On 07.12.20 19:34, Florian Schmaus wrote:
> We do have xml:lang, don't we?
Unforunately, it doesn't help in all cases. It's perfectly fine to write
a message with xml:lang="en":
> "chlapec" is "boy" in slowak
This is 27 grapheme clusters, but I guess most western people would
count it as 28
Hi,
On 04.12.20 21:23, Florian Schmaus wrote:
> And I am in favor of code points because it allows us to aim for the
> extended grapheme cluster algorithm, while also allowing for the
> "simply count code points" fallback.
XEP-0426 already discusses why it's using codepoints instead of
grapheme
Hi,
On 24.11.20 21:40, Ivan Vučica wrote:
> Since this now refers to deferred XEP-0103, will that one be advanced
> again? Maybe changed to experimental or draft, possibly marking the "use
> with SI" session as deprecated (since session initiation itself is
> marked deprecated)?
XEP-0103 is used
Hi,
On 24.11.20 22:20, Ivan Vučica wrote:
> However it also seems to me like the current spec might be suboptimal
> in case a sticker pack wants to provide PNG + animated GIF + any other
> media format. For instance, I may provide an animated GIF thumbs up,
> an animated PNG thumbs up, but also a
Hi,
On 19.11.20 15:29, Jonas Schäfer wrote:
> - I do not like the dimensions element carrying two values. I suggest to use
> separate width/height elements. Same motivation as for 1st normal form for
> databases.
Agree. Not sure where I copied that from, but splitting in width/height
definitely
Hi,
On 19.11.20 12:04, Dave Cridland wrote:
> * Indicate to clients that if they're just going to display the body
> tag, then they are missing something. There was some suggestion - from
> Georg I think - that it might be useful to include the XMLNS of the
> element that obviates the body.
This
Hi,
On 19.11.20 15:03, Sam Whited wrote:
> IMO what this spec should do is ensure that there is a way to subscribe
> to notifications that a sticker pack has been updated, but not the
> actual sticker data (which can then be fetched later). I am not sure if
> pubsub gives us a way to do this on it
Hi,
On 18.11.20 18:08, Dave Cridland wrote:
> 1) Use of fallback body
>
> I really dislike this as a general mechanism, but at least let's mark it
> using XEP-0428 (and if that's not quite right, let's fix it).
I was under the assumption that marking fallbacks using XEP-0428 is a
thing described
On 10.11.20 15:23, Jonas Schäfer wrote:
> In this case, please discuss the security implications in regards of
> phishing.
> With sender-side rich preview, spoofing of such previews becomes trivial. I
> imagine a spoofed rich preview to be even more dangerous than the typical href="badsite">goo
Hi,
Beside what Jonas said, there is two things I'd like you to consider
when specifying this that seemed to be out of scope or not considered yet:
## Support sender-side link generation
According to various security/privacy people, the best way to do these
link previews is to generate them clien
Hi Dave,
Thanks for your message. From my experience with mobile phone networks
when traveling in Germany (not sure if it applies in other countries, as
German mobile networks are far below average in my experience), I can
confirm that temporary connectivity loss is not handled perfectly well
in s
Hi Manuel,
XEP-0333 Chat Markers are sent by clients, not servers. They are also
typically sent to all clients that participate in the conversation (i.e.
the recipient, other devices through carbons, participants in a MUC,
...) and for all of them except the sending device such `sent` marker
would
On 29.09.20 17:36, Dave Cridland wrote:
> Note that I sympathise with this argument. However, I would also note
> there are plenty of clients and client libraries which do a perfectly
> good job of generating random ids already, and forcing them into using
> UUIDv4 might be more painful.
How ca
On 29.09.20 12:23, Dave Cridland wrote:
> * UUIDv4 becomes an "advised to use"; the requirement is uniqueness. I
> think UUIDv4 is a good thing, and people are unlikely to get anything
> wrong if they use this method, but I don't think there's any
> interoperability issue with using something diffe
I think there is two problems that are somehow merged within this:
1. Knowing the last outgoing message's server stanza-id for the purpose
of fetching only newer messages with MAM.
2. Knowing all outgoing message's server stanza-id, for undefined purpose.
While any solution to 2 also solves 1, i
On 02.06.20 22:34, Sam Whited wrote:
> This does not add new rules, [...] I was hoping to avoid
> adding extra rules anyways, and making category C another thing that's
> disallowed counts.
You are contradicting yourself, but I guess we were thinking the same
nonetheless ;)
>> Solution could be:
>
Hi,
1. I don't think we should add new rules, especially none that are hard
to implement - and most people (and also many programming languages)
have trouble with unicode, so I'd qualify this as hard to implement.
2. I also disagree that category C characters should not be allowed to
appear after
Hi Sam,
Unfortunately your updated §7.1 is broken.
- U+2060 WORD JOINER is not a whitespace character under Unicode
definition, therefor your proposed way to remove styling will not work
with any client correctly implementing the XEP.
- U+200B ZERO WIDTH SPACE is also not a whitespace character (
Hi Jonas,
On 02.06.20 16:26, Jonas Schäfer wrote:
> I think we disagree fundamentally, though, on whether this is an advantage,
> or
> at least as a necessary advantage. It necessarily implies that if a client
> does not have support for it, I have no way to opt out if I know that my
> message
Hi,
Sorry, long mail ahead.
I'd like to express that I am very much unhappy where this is leading.
While I am personally not a big friend of inline message styling, I kind
of feel that the party of non-likers (or parts thereof) is trying to
make the XEP to something that is mostly useless instead
Hi,
On 25.05.20 15:29, goffi wrote:
>
> yes that's the idea. Not `styling=inline` because we don't use
> namespaced attributes and thus I don't think we can add an to ,
> but something after the body like `
Hi,
On 18.05.20 14:48, Sam Whited wrote:
> What would you think
> about changing that language to a MAY just to make sure the idea stays
> in peoples heads but so that we have softer language? The point was
> supposed to be that this is an implementation and client choice.
I do think the XEP shou
On 12.05.20 21:35, Jonas Schäfer (XSF Editor) wrote:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
This XEP tries to fill the gap of lack of formatting instructions
introduced by deprecating XHTML-IM (XEP-0071).
> 2. Does the speci
Hi,
On 10.05.20 21:41, Daniel Gultsch wrote:
> To be clear the fallback I have in mind is for implementations that do
> support Jingle RTP sessions but not Jingle Message Init.
> In those cases you clearly don’t want to fall back to sending a link
> but just initiate the session directly with the
Hi,
Mostly unrelated to Daniel's feedback, but an idea regarding JMI that is
my head for some time now.
One thing I am missing in XEP-0353 is explicit support for legacy
fallback body. Which may sound absurd at the first second, isn't to me:
The fallback body could include an https URL to a webs
Hi,
On 07.05.20 18:34, Sam Whited wrote:
> Can we modify the mechanisms feature? Having this be an extension to the
> mechanisms feature seems problematic to me.
Extensibility inside the element is part of RFC6120. The
schema at https://www.rfc-editor.org/rfc/rfc6120.html#appendix-A.4
explicitly
(inline)
On 4/21/20 4:51 PM, Tim Henkes wrote:
> The question here is, why make a difference between "legacy" clients and
> clients with support? Why hide that an action was performed from users
> with supporting clients and show that an action was performed to users
> of "legacy" clients?
Well,
(inline)
On 4/21/20 2:32 PM, synd...@web.de wrote:
> Verbosity is something that may sometimes be desired, but sometimes
> duplicate or annoying. Take the example of the merge again: as soon as
> you select the "merge" action, the bot performs the merge and then
> probably sends a new notification
Hi,
To me that still sounds like the only major difference is that actions
are not backwards compatible.
I understand that action IDs can be just random, however I wonder what
the usecase of such is that couldn't be realized using a human-readable
text.
Looking at the example in the XEP, the act
Hi,
Do I see it right, that the only relevant difference between a
"Response" and an "Action" is that legacy clients will display a
selected Response as message but won't display a selected Action at all?
Was it a deliberate decision to not have a fallback body for Actions?
Marvin
On 4/21/20 12
Hi,
> At the Summit, I've suggested to send all required data within Push
> notification,
> but for security reasons, encrypted by XMPP server initiating push
> notification.
> Here is a document which describes encryption process done by us at Tigase
> https://tigase.github.io/tigase-xeps/docs/
Hi,
Very much appreciate people working on MUC again. This feature is
definitely needed.
Nitpicking on the syntax: The current XEP suggests to add the ver
attribute to the {http://jabber.org/protocol/muc}:x and
{http://jabber.org/protocol/muc#user}:x elements. IMO, it would be
better to put a new
XEP-0184 is doing one job, that is to notify the sender when a message
was delivered to the recipient's client. That's literally what the title
is. While in setups with MAM and SM, far less messages get lost, the
pure specification of XMPP does not guarantee every message to be
delivered to the rec
While I do like the idea, I think this could be done more elegantly
using a generic "send a message later" functionality. That way the
reminder can also be send to others and can also have arbitrary message
content. However such feature would require the own server to implement
that feature (wherea
Hi,
On 2/19/20 1:33 AM, Dave Cridland wrote:
> But honestly I think choosing to go such a route would be overkill. I
> understand the sentiment, really I do, but the fact is people seem to
> look for the simplest solution to getting JSON over the XMPP session,
> and I think that's probably what we
The new XEP still uses the shortname "udt", has it in schema and also
mentions UDT in the §2.2, without there being any description of what it
means. I guess you just forgot to update those. This is likely to cause
confusion if left like this (especially the one in §2.2).
My only main critique tha
On 1/17/20 10:53 PM, Dave Cridland wrote:
> In my experience, a lot of the draw for XMPP is the fact
> it's an off-the-shelf solution with interoperable pieces. That's (at
> least) a by-product of standardization.
I see your point but I fail to see how it counters my point. If they
only care about
On 1/17/20 11:38 AM, Dave Cridland wrote:
> Well, yes, but the majority of our end-users are probably Fortnite
> players, and they're not talking to us.
I should have been more precise: I was talking about the open XMPP
ecosystem, not any closed/walled garden XMPP implementations with own
client/se
On 1/17/20 11:05 AM, Kevin Smith wrote:
> Yes, I agree with what I think you’re saying - if there is a spec published
> that does what someone needs, they will implement it regardless of what the
> state says at the top (or any warnings about readiness). The “Inbox+” idea
> mostly just accepts t
On 1/17/20 10:29 AM, Kevin Smith wrote:
>> I need a feature X *now* and all I see is
>> an experimental XEP I have two choices; Implement that Experimental
>> XEP or create something myself.
> I don’t think making the barrier to entry to Experimental lower (or Draft)
> will change that fact, so if
See, this discussion is not going to go anywhere. We do have different
opinions. I am fine with that. Yes, this means additional work for both
of us. Yes, this means we'll likely have opposing XEP proposals for some
time. I am fine with that. Let's just keep it at this.
On 1/8/20 11:06 PM, Dave Cr
On 1/8/20 5:25 PM, Florian Schmaus wrote:
> After briefly reading this thread, it is my impression that Dave wants
> to pursue a generic approach to referencing/linking/fastening messages
> and the related MAM retrieval, while you argue that a use-case specific
> approach is required (at least in
1 - 100 of 134 matches
Mail list logo
