jonaswthe asterisk is defined in: https://tools.ietf.org/html/rfc2234
jonaswas: The operator "*" preceding an element indicates repetition. The full
where <a> and <b> are optional decimal values, indicating at least
<a> and at most <b> occurrences of element.
Default values are 0 and infinity so that *<element> allows any
number, including zero; 1*<element> requires at least one;
3*3<element> allows exactly 3 and 1*2<element> allows one or two.
jonaswthis means that *( foo ) is zero or more of foo
jonaswin this case it means that ihost can be empty
jonaswthus it is legal to have an empty JID *as per the grammar*
jonaswI haven’t checked the text yet :)
jonaswthe same holds for the URI interpretation, but without the leading "i"
jonaswit might be an oversight that the grammar allows it, but it’s useful in this case :)
marcMaybe I need to read this document thoroughly, there is also something like "xmpp://email@example.comfirstname.lastname@example.org?message"
Ge0rGmarc: I've been pondering about the invitation workflow some more, and I think it should go like this:
1. you request an invitation token from your server via ad-hoc
2. you send a url of xmpp:you@yourserver?roster;invitation=token out-of-band
3a. the invitee performs IBR with the invitation token
3b. the invitee already has an account and performs PARS with the invitation token
marcGe0rG, what is you@yourserver? The JID of the inviter?
marcGe0rG, the client still must provide the possiblity to create an account even if you already have one
Ge0rGmarc: in theory, yes. But I'm pretty sure the power users will figure it out anyway, and the regular users will only get confused
marcGe0rG, if you already have one you'll probably know what to do if the client provides you a dialog so it shouldn't be a problem, right?
jonaswmarc, FWIW, if you really want that feature, I’d hide it at the bottom of the screen
jonaswlike websites hide the "continue without" button when asking for your phone number :)
marcjonasw, maybe I want to give a user the possibility to join _my_ server
marcI think that feature is not unreasonable
jonaswmarc, I doubt that many users care a lot of about that.
Ge0rGthe default flow should be as easy as possible.
marcyes, the default user has no account :P
marc-> the default user will not be confronted with a dialog
marcGe0rG, I'm not sure about the ?roster action
Ge0rGmarc: I don't care about the action too much
Ge0rGmarc: but there will be a dialog, either account creation or add-contact
marcGe0rG, Yes, if you already have an account there should be an "add-contact" dialog with an option to create an account
marc(instead of just use an existing account)
daniel> you send a url of xmpp:you@yourserver?roster;invitation=token out-of-band
shouldn't that be xmpp://you@yourserver or something
Ge0rGmarc: if the client supports multiple accounts. which is arguably a power-user feature that makes UX complicated
jonaswdaniel, are you asking because of the semantic difference between xmpp:// and xmpp:?
Ge0rGdaniel: no, :// would be an account reference, : is a contact reference
marcI had the same idea
marcbut the authority is to indicate the account to use
danieloh i thought you was I
daniellike you the proposed username for me
Ge0rGdaniel: you could do something like xmpp://proposed_invitee_jid@server/inviter@server
marcGe0rG, why does it lead to a complicated UI? Just a small button "Create account" in the bottom left/right corner
danielGe0rG, yeah i thought that's what this thing was trying to do. never mind
Ge0rGmarc: the complicated UI arises when you have multiple accounts
Ge0rGmarc: now you need a notion of a default account, or ask the user on every interaction which account to use
danielmarc, have you considered what communication method I would use to send you the url?
danielbecasue gmail for example doesn't make xmpp uris clickable
danielneither does the sms app
marcGe0rG, you already have to ask the user what account to use
marcdaniel, we use an invitation url
Ge0rGdaniel: I would love to anchor that onto the easy-xmpp-invite mechanism
Steve Killehas left
Steve Killehas left
danielmarc, like an https url?
Ge0rGmarc: that's exactly my point, it's a UX nightmare.
danielwhy are you discussing xmpp uri schemes then?
marcdaniel, that's an other topic ;)
Ge0rGit's all interrelated.
danielonly that xmpp uris are mostly worthless
danielwhen it comes to easy onboarding
edhelaswas difficult to figure out those xmpp uris as well for me
Ge0rGdaniel: right, so I've made easy-xmpp-invitation.
Ge0rGdaniel: which allows to bridge xmpp: URIs over https.
danieledhelas, it's not that they are difficult. but you can't click them
jonaswdaniel, you can make any URL clickable on a website -> win
Ge0rGjonasw: but it won't magically work.
marcGe0rG, I don't get what's the problem with multiple accounts. We already have clients that support multiple accounts.
marcAnd there is almost no additional work for the UI
Ge0rGmarc: I'm not saying that implementing multiple accounts is a problem, I'm saying that having multiple accounts on the same client is a UX nightmare
Ge0rGmarc: imagine a user accidentally clicking the "create account" button and ending up with two accounts - one for all their friends and one for you
Ge0rGand users have very large fingers.
marcGe0rG, yes, that needs to be solved by the UI nicely :D
marcThat's why the preferred option is to add the contact via PARS if an account is available
Steve Killehas joined
marcBut creating a XEP just for user invitation to a server if the user doesn't already have an account limits the possibilities...
Ge0rGmarc: right, which is why the whole thing is also technically a bit more complex
marcGe0rG, my problem at the moment is that I'm not sure how to integrate both XEPs properly
marcIn a way that both do not depend on each other and can be implemented independetly
Ge0rGmarc: you need to have four specifications:
- token generation (PARS uses a client-side approach, you go with ad-hoc. specify that)
- token transmission (basically a new xmpp: URI parameter)
- use of the token in account creation (IBR payload / data forms)
- use of the token in PARS (just reference PARS and say that the token must be usable as `preauth=` for PARS as well)
marcGe0rG, yes, but the tokens need to be the same if both is used
Ge0rGthe server needs to store the token in some kind of table anyway, where it will also contain the inviter's JID
Ge0rGmarc: I think that re-using this token for server-side PARS shouldn't hurt
Ge0rGmarc: so your specification means a server must implement PARS
Ge0rGmarc: or, alternatively, you need to add two tokens to the URL
Ge0rGActually, I would be okay with extending PARS accordingly.
Ge0rGSo that it covers both use cases.
marctwo token keys with the same token, like invite=TOKEN;preauth=TOKEN ?
marcSuch that the clients know that both is supported?
Ge0rGmarc: yes, like that.
Ge0rGmarc: or maybe invite_and_preauth=TOKEN ;)
Ge0rGI like short URIs
Ge0rGmarc: I would go for `invite=TOKEN` and "A server offering this feature MUST also accept the token as a <preauth token> for an inbound roster subscription to the inviter."
marcSo implementing user-invitation requires implementation of PARS, right?
Ge0rGmarc: not technically, but if you want to provide a good UX then yes
marcGe0rG, Yes, for nice UX I would prefer it this way
marcGe0rG, your statement sounds like a requirement
Ge0rGmarc: you could go with two separate token parameters, then you have explicit separation between PARS and IBR. But then who is responsible for adding PARS to the URI? The server on ad-hoc? The inviter's client?
marcGe0rG, the server if it supports PARS?
Ge0rGmarc: in the ad-hoc response?
jonaswGe0rG, for breveity, the URI could also be ?invite=TOKEN;preauth=, with the empty preauth signifying that the token shall be re-used
Ge0rGjonasw: then you are breaking existing PARS clients :P
jonaswthen turn it the other way round :)
Ge0rGjonasw: the more I think about it, the more I want to merge both functions into one XEP
marcGe0rG, yes, in the ad-hoc response
marcGe0rG, are there any PARS clients out there? :D
Ge0rGmarc: there is yaxim
marcGe0rG, ah okay
jonaswit’s on the to-do for jabbercat
marcGe0rG, well, I like your idea of combining both "features" but they should not be depend on each other IMO
Ge0rGmarc: that depends on your goal
Ge0rGmarc: if your goal is to make as little as possible, then you are right. If your goal is to provide a just-works™ onboarding experience, you need both.
marcThe combination of both would make on-boarding really nice
marcGe0rG, of course, providing both should be recommended for public servers
Ge0rGmarc: I'm all in for small self-contained XEPs. But if you separate these two, you have a bunch of additional client-side logic to add to compensate for the lack
Ge0rGon the inviter's client: "oh, ad-hoc didn't give me a PARS token. I need to add one to the URI myself. Wait, the https:// URI is not a scheme I know, I can't do that!?"
Ge0rGon the invitee's client, I need to cover all four combinations of features
Ge0rGnone / invite / pars / invite+pars
marcGe0rG, no, the server just adds the PARS token and returns it
Ge0rGmarc: but the server doesn't support PARS, only the client.
Ge0rGI've designed PARS as a client-only protocol because server developers are lazy.
marcGe0rG, ah okay, didn't thought about that use case
Ge0rGAnd server operators are even lazier.
jonaswyeah, server developers aren’t that lazy
marcGe0rG, that's a good point... hm...
Ge0rGmarc: you implement your nice new server-side XEP. Then it takes weeks to months for it to get merged upstream. Then you need to wait for the next server software release. Then that release needs to be distro-packaged. Then you realize that most server operators never upgrade.
marcGe0rG, well, that's true for all server-side XEPs
marcGe0rG, should be implement everything on the client side?
Ge0rGmarc: now you know why PARS can be implemented 100% client-side
jonaswGe0rG, I think it might be not /that/ bad
Ge0rGmarc: Daniel's compliance tester is a good thing to make server operators aware.
jonaswwe’ve seen quite quick adoption of things since conversations compliance checker
Ge0rGjonasw: especially private PEP.
jonaswso if somebody builds a prosody module which does that, even if it only supports things in-memory, that’ll already be a major plus
jonaswGe0rG, yes, we have. A lot of work is going into that :)
Ge0rGyou can't force server developers to do work by showing a red square on some website
marcGe0rG, to solve this issue we need an "official" public server list on the (xmpp.org?) website
jonaswto solve that problem we need massive funding for developers.
marcwhich shows only servers with a special set of XEPs
Ge0rGjonasw: how many servers are there in the compliance checker? ~120? yax.im has >1000 of s2s connections.
Ge0rGmarc: we can't even come up with that official set of XEPs.
danielGe0rG: divide that number by 4
danielBecause in and out and conferences
Ge0rGmarc: but yes, we need an official compliance checker, and maybe some kind of Badge Of Compliance that we can issue. Do you volunteer?
Ge0rGdaniel: `Total: 1112 outgoing, 1079 incoming connections` - not sure how many MUCs there are, but cant' imagine it's 50%
marcGe0rG, let me first finish my URI handling in Conversations and the user-invitation XEP ;)
jonaswGe0rG, depends on what you want to check, the aioxmpp end-to-end test suite might be a good start :)
marcGe0rG, but I think that's really important
Ge0rGmarc: what's important?
marcGe0rG, some official server list
Ge0rGmarc: xmpp.net had a semi-official one.
Ge0rGbut now it's down and needs work to bring up again.
jonaswyeah, about that xmpp.net thing, Kev, I’m still hoping for your Dockerfile :)
marcif you have created an account on a server which doesn't support, let's say HTTP upload, and file transfer in group chats doesn work this user will be annoyed and probably will never use / recommand XMPP
Kevjonasw: Let me sort that out now.
jonaswKev, that’d be lovely
jonaswI’m tempted to sink my weekend into getting xmpp.net up&running again
jonasw(and then people wonder why jabbercat isn’t making progress)
jonaswhold yer horser
jonaswsave the praise for when I’m done
jonaswI might easily get fed up by PHP
KevWhat is jabbercat, BTW?
Guus(by the way, why isn't jabbercat making progress?)
jonaswKev, https://github.com/jabbercat/jabbercat, TL;DR: new Qt5 Desktop Client
KevBecause we don't have a Qt5 Desktop client already? :)
Ge0rGit's a very promising early alpha
marcGe0rG, to speed things up "we" should decide how we implement PARS and user-invitation
jonaswKev, frankly, when I started, I didn’t know / forgot about Swift & co.
Ge0rGThe Swift bug tracking situation is not optimal. I've submitted a bunch of things and I have no clue whether they got fixed or not.
Ge0rG(except for the wontfix ones)
Ge0rGmarc: let me help you with that. We integrate account creation into PARS.
marcGe0rG, okay, and what's the protocol flow then?
Ge0rGmarc: ad-hoc -> xmpp: URI with optional https: URI -> out-of-band -> IBR/PARS request
marcGe0rG, so the server generates / appends an additional PARS token if enabled?
Ge0rGmarc: if the server doesn't provide an https: URI, the client can either pass on xmpp: or use its own landing page (eg. https://yax.im/i/)
Ge0rGmarc: there is no "if enabled"
Ge0rGand there is only one token, that can be used for both
Ge0rGNo, that won't work for closed-registration servers.
marcYeah, that's somehow my problem ;)
KevGe0rG: Nothing is optimal :)
Ge0rGjonasw: the xmpp: URI needs an indicator whether registration is allowed.
marcBecause that means that somebody may propose just an other XEP for it...
Ge0rGwe could go with `xmpp://server/inviter@server;preauth=TOKEN` - `server` is explicitly telling us the domain where to register, the inviter JID is present and a token that can be used for either.
Ge0rGBut that will break most current clients that support xmpp:
Ge0rGshould we provide means for the server to specify a different domain from the inviter's?
jonaswGe0rG, will it though?
marcGe0rG, yes we should, I also had this idea :)
Ge0rGjonasw: when you open an xmpp://email@example.com link, I'm pretty sure unexpected things will happen.
marcyes, I think the XmppUri parser in Conversations is broken
jonaswI’m pretty sure I’ll get "unknown protocol" because I don’t have an application which supports XMPP URIs at all
Ge0rGthe URI parser on android is broken as well
marcAt least it doesn't support the authority part properly AFAIK
> If the server allows In-Band-Registration with the preauth token, it SHOULD add an `ibr` parameter. If the IBR domain is different from the inviter's service domain, the server should set the value of the `ibr` parameter to the domain name.
Ge0rGSo we would end up with: `xmpp:firstname.lastname@example.org?preauth=TOKEN;ibr=yax.im`
marcGe0rG, should we really avoid using XMPP URI properly just because some clients don't implement the parser properly?
Ge0rGmarc: we are using the URI properly.
Ge0rGmarc: the primary goal of the URI is to add a contact, not to register with the server
jonasware we? wouldn’t xmpp://email@example.com be more correct?
marcWhat about xmpp://server/inviter@server;preauth=token` then?
marcI think jonasw is right
Ge0rGmarc: so your goal is to force the invitee to register with your server?
marcGe0rG, yes, at least it would be nice if we have an option for this use case
Kevjonasw: How do you want this tarball?
marcGe0rG, because I'm pretty sure my server has nice XEPs enabled ;)
jonaswKev, deep fried
Ge0rGmarc: maybe we have different goals, then? I want to give out a link that allows the receiver to add me as a contact, and to create an account on the way if required
jonaswI just wish this was all working before end of year :D
Ge0rGmarc: if you want to "entice" the receiver to re-register on a different server, I don't agree.
Kevjonasw: This is stuff for running up a symfony-based PHP thing, so you might want to trim some of the bits out - e.g. I have no idea if the frontend needs to install depedencies with composer. There might or might not need to be crontasks, trim that out if not, and you might or might not need to populate an environment file of some sort.
Ge0rGmarc: but in that case, the xmpp://server/inviter@server would be semantically correct.
jonaswKev, thank you very much
marcGe0rG, don't get me wrong, my intention is to make easy onboarding....
jonaswgotta head out now for lunch, will take a look later :)
Ge0rGmarc: right. And onboarding without having to create an account is easier :P
jonaswFWIW, marc, I think we shouldn’t encourage non-power users to have multiple accounts.
Ge0rGwhat jonasw said.
jonaswit should be there if they need and want it, but we shouldn’t make it the default path for the unthinking chicken installing debian :)
jonasw(hitting enter / the big button on each step)
jonasw(this is not to insult our users, just making a reference to the old joke that even a chicken can install debian by simply hitting on the Enter key repeatedly)
jonasw(and I think that it should be that easy to use XMPP)
marcI agree, but to me it looks like we miss some useful feature in the XEP then
Ge0rGmarc: what would that useful feature be?
marcGe0rG, somebody is on a shitty server? :D
Ge0rGmarc: this is not a feature of the XEP
marcwell, it's user invitation
Ge0rGmarc: what about having a "server quality index" display in all clients, that can estimate how good the current server is, and how good the proposed one? :P
Ge0rGmarc: well. You can have the "Create new account on [ibr server]" button in the add-contact UI; and then you write into your invitation mail to click that button :P
marcGe0rG, if we don't have this feature there is no way to invite a user to a non-public server
Ge0rGmarc: my point is, what if you are on a shitty server and I'm not?
Ge0rGmarc: by non-public you mean non-federated?
marcGe0rG, no, just a server where only registered users can invite somebody
marcGe0rG, I think there are some reasons to join a specific server even if an user has already an account, privacy/trust etc.
Ge0rGmarc: to invite a user to a non-federated server, the correct URI would be indeed `xmpp://server/inviter@server?ibr;preauth=TOKEN`
marcThis wouldn't be possible and IMO that's not good if we have the chance the include this
marcGe0rG, non-federated server is not the correct term
marcJust because a server doesn't allow public registration it can still be federated...
Ge0rGmarc: if it allows federation, there is no need to force non-power-users to create a second account
marcGe0rG, even if the user is a "power-user", how to easily invite the user? via a web-interface / shell just because the XEP doesn't support this feature?
jonaswI think you two are misunderstanding eaxh other
jonaswGe0rG wants to keep the account creation, but not as default
marcWell, I'm fine with that :)
marcIt shouldn't be the default but it should be _possible_
marcAnd, maybe that's the controversal part (?!), PARS should be optional
marcHm, maybe that's not too important
marcI don't know
Ge0rGmarc: why do you think PARS should be optional?
Ge0rGmarc: the first button is prominent, the second button is toned down, like "skip registration" would be
FlowGe0rG, so JID and Name are editable text fields?
Ge0rGFlow: the JID is visible but not editable, the name is editable
Ge0rGFlow: one might want to add a roster group selector as well.
FlowHmm, how about "Invitation from Georg (georg@yaxim)" then?
marcGe0rG, if we agree on the possiblity of predefines usernames (optional) we're almost done :D
Ge0rGmarc: please don't.
Flowand why is there a [create yax.im account] button?
Ge0rGFlow: what's wrong with the above? You can reuse your regular "add contact" dialog and just disable JID editing
marcGe0rG, but it allows me as admin to create an account for an user
marcAs I said, optional, server-side option, maybe for admins only etc.
marcNot useful for public servers
FlowGe0rG, ok, if that is the idea. But I would proably go for a specialized UI
Ge0rGmarc: if you already created an account, you should use xmpp://user@server?preauth=TOKEN
Ge0rGFlow: [create yax.im account] is for power-users who want to have an account on the same server as the inviter.
marcGe0rG, well the user still has to specify the password
marcSo ibr is still correct I think
Ge0rGmarc: I think this is a completely different use case.
FlowGe0rG, but UX usually means to hide operating elements for power useres
Ge0rGFlow: tell that to marc
Flowgood thing a protocol can't require how the UI looks like
Ge0rGFlow: actually that's a bad thing, in most cases.
FlowGe0rG, require or suggest? ;)
Ge0rGExcept when protocol designers try to create a UI :P
Ge0rGBut yeah, I think that hiding the account creation behind an "Advanced..." button would be good.
marcGe0rG, sounds good
Ge0rGmarc: we really do need a way to "export" an account to a new device, or to one-click register, but I think this is a (slightly) different use case
marcGe0rG, just let me know what's the big difference between "you have the option to create an account or add the contact to your roster" and "you have the option to create an account with full JID or add the contact to your roster"?
Ge0rGmarc: what you are looking for is, as an admin, to pre-create an account and give the user enough info to just configure a password.
Ge0rGmarc: what I'm looking for is to add a contact, and to create a user-defined account if required.
marcGe0rG, do you really think it's worth making an extra XEP for that?
Ge0rGmarc: if you pre-created an account, you want your invitee to use that.
Ge0rGmarc: I only want to give the invitee the option to create an account themselves
marcGe0rG, what's the down-side of allowing this optional feature?
Ge0rGmarc: because this optional feature must be implemented by all clients
marcokay, that's a reason
Ge0rGmarc: every time you add an option to a protocol, you double the number of possible situations
marcBut the code is very small
marcGe0rG, I know I've implemented it in conversations
marcYou just have to check if that's a full JID or just the server name
Ge0rGmarc: so with optional inviter name, optional invitee JID, optional https:// URL, and the option to already have an account we are at sixteen different cases already.
marcIn the latter case you have to fix the server name in the JID text entry
Ge0rGmarc: I see two different, but related use cases:
1. you want to onboard someone to a pre-registered account on your server. Use `xmpp://user@server?preauth=TOKEN`
2. you want to add a contact. Use PARS with an `ibr` option.
Ge0rGmarc: I think that is absolutely out-of-scope
pep.They'd be able to generate tokens etc.
pep.You can traceback where it came from though
marcGe0rG, we should at least define an error for that
Ge0rGpep.: right, one could easily kick the spammer and all of their friends.
marcGe0rG, nothing is more annyoing to a user if you get something like "doesn't work at the moment, try again later!"
Ge0rGmarc: I'm sure we can re-use existing IBR errors
marcGe0rG, I mean for token/invitation generation
Ge0rGAnd there is https://xmpp.org/extensions/inbox/user-auth.html
Ge0rGmarc: the ad-hoc command should always return a token, just maybe not with an `ibr` tag.
marcGe0rG, that would be confusing ;)
Ge0rGmarc: to whom?
Ge0rGmarc: the default use case is to generate a PARS uri
Ge0rGmarc: if you are talking of the admin use case, yes, it should return an error.
marcsometimes you have the ability to create an account sometime not?
Ge0rGmarc: for the user use case, the server generates a PARS or a PARS;ibr link
Ge0rGmarc: depending on whether user-initiated account creation is allowed on the server.
Ge0rGmarc: a non-ibr PARS link will mean that the invitee's client is responsible for account creation
marcGe0rG, just thought about the case where an inviter creates too much PARS;ibr tokens
marcMaybe you want some policy to limit the number of PARS;ibr tokens
Ge0rGmarc: maybe. But there is no need to expose that to the inviter's client
(1) Marc invites somebody without account -> server generates PARS;ibr -> nice
(2) Marc invites somebody without account -> server generates PARS only -> invitee and Marc are confused
marcGe0rG, maybe I don't get your idea but this is how I understood your approach
Ge0rGmarc: (2) Marc invites somebody without account -> server generates PARS only -> invitee opens link in yaxim and registers on yax.im -> nice
marcGe0rG, sounds like a bad idea to me... not every client provides a xmpp server?
Ge0rGmarc: no, but the ones implementing PARS do :P
marcGe0rG, Does PARS require a client software to provide a xmpp server?
Ge0rGmarc: actually, I forgot to add that part to the XEP
Ge0rGmarc: but yes, I think that a client implementing PARS needs to have a sensible user-onboarding flow that does not depend on the invitee.
jonaswGe0rG, so jabbercat better doesn’t implement PARS
Ge0rGmarc: it doesn't mean the client developer must run an IBR server, they can provide a list of public servers instead
jonasw(I won’t get into the business of running a public server.)
Ge0rGjonasw: you can SRV-link jabbercat.im to the yaxim server :P
marcGe0rG, okay, I think I'm okay with your idea
jonaswGe0rG, will do
Ge0rGjonasw: I'm pretty sure I can handle the additional load
Ge0rGjonasw: btw, did you buy out jabber.cat already? :P
jonaswtoo politically unstable that TLD ;-)
Ge0rGStill better than .io
marcAlthough it may be very confusing if that happens to invitees who sit next to each, for example ^^
jonaswdoes im have DNSSEC by now?
Ge0rGmarc: why so?
marcGe0rG, because they don't get the same dialog
marcGe0rG, invitee A an create an account on the server and invitee B can choose some public server
jonaswGe0rG, but then I want private+persistent PEP on jabbercat.im!
Ge0rGjonasw: please star & comment on https://prosody.im/issues/485
jonaswI won’t comment, Zash hates that
jonasw> PEP with permanent storage is now in mod_pep_plus and should be working. Thanks to Link Mauve!
pep.Yeah, that's in trunk
Ge0rG> Is this feature usable with 0.10?
pep.0.10, pff :)
edhelasjust to give you ideas, in Movim I've implemented an invitation system for MUC that generate a unique link https://nl.movim.eu/?login/GA1dbdSB
edhelasonce the user login it automatically ask him to add the MUC to the bookmarks and join
edhelasit's a bit like Discords in doing
Ge0rGedhelas: web-based stuff is easier
jonaswI want that MUC invite integration thing
Ge0rGedhelas: can you make it work with PARS and easy-xmpp-invitation? :P
Ge0rG"Timothée Jaussoinhat Sie eingeladen, einen Chatraum zu bet..." - the UI is cut off.
GuusThat's what you get for inventing such long words in your language!
Guusshees, you're almost as bad as the Finnish!
edhelasthere's never enough place to display german messages
pep.it's also cut off in english
jonaswGuus, don’t insult the finnish
Ge0rGedhelas: which is why German is a good UI testing language.
jonaswthey’ve got the most amazing language on this continent
jonaswyeah, long words and long sentences :)
edhelasthey beat all of us at the Scrabble
pep.edhelas, where is that in the UI btw? Where do I generate that
Ge0rGMy favorite was a bug report by a user that my app was lacking a button. It took me a looong while to find out that on some Android version, the OS developers removed text-wrapping from buttons, and the "OK" button was outside of the dialog
Guusjonasw: I'm always laughing at subtitles Finnish tv, where one of the lines (Swedish), has words, and the other line (Finnish) has _a word_.
jonaswthat’s how amazing it is!
edhelaspep. in a chatroom, click Menu > Invite
Ge0rGhttps://stackoverflow.com/questions/26708976/alert-dialog-buttons-problems-in-android-l - this one, except that in my app, the button was completely gone!
Ge0rGShould the ad-hoc command node be a human-readable short string or a unique identifier / URL?
Ge0rGprosody is using URLs as node names, the XEP is using short identifiers.
Ge0rGI'm not talking about the 'name' field but about 'node'
jonaswURLs is probably safest
Ge0rG> Service Discovery requires that all 'node' values be unique within a given JID. This document requires that the 'node' value used in <command/> exactly match the value used in the <item/> element. It is the responsibility of the responder implementation to ensure each command's node is unique for their JID.
So short identifiers are valid as well, unless you support plugins that add more nodes.
Ge0rGSo for the sake of implementing an invitation ad-hoc-command, it should be a URL as well? Hmhm.
jonaswone could probably re-use the URI the XEP will allocate