User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
Admin
completely blind computer geek, lover of science fiction and fantasy (especially LitRPG). I work in accessibility, but my opinions are my own, not that of my employer. Fandoms: Harry Potter, Discworld, My Little Pony: Friendship is Magic, Buffy, Dead Like Me, Glee, and I'll read fanfic of pretty much anything that crosses over with one of those.
keyoxide: aspe:keyoxide.org:PFAQDLXSBNO7MZRNPUMWWKQ7TQ
Location Ottawa
Birthday 1987-12-20
Pronouns he/him (EN)
xmpp fastfinge@im.interfree.ca
keyoxide aspe:keyoxide.org:PFAQDLXSBNO7MZRNPUMWWKQ7TQ
blog https://stuff.interfree.ca/
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae Then they're not an XMPP compatible client, and servers should just drop them with an error.
1
0
1
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae But because the standards are defined, and capability negotiation is part of them, you always know what the other person's client supports, and what both of your servers will allow. With deltachat, that's impossible. And my grandmother uses the console and runs a text based client. She can never run deltachat apps. But her client can never tell any other client it interacts with about that limitation.
0
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae Yup, it sure does! XEP-0030 allows any client or server to be queried about exactly what features it does and does not support.
1
0
1
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae in reply to, yes. See: cr.yp.to/immhf/thread.html
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae So then my grandmother gets strange inexplicable zip files from her cousin who wants to play a Wheel of Fortune game together. And neither my grandmother nor my cousin can understand why it's not working. My cousin, in fact, would have no way of knowing the app she sent did not run. That's a terrible experience all around.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae Showing message threads, the way slack and discord do, and having multiple threads in a single chat.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae It's really not. To know what a server supports, you just ask it. And it will return the list of capabilities it has in a standard way. Same for other clients. Service and capability discovery are solved problems. Deltachat seems to just ignore them completely, because the expectation is that everyone should just use libdeltachat.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae Also, if I choose not to implement deltachat apps in my chatmail client, what is the method of capability negotiation that I should use to indicate that to the deltachat app, and let that user/app know what features I do and do not support? What if I create shiny feature X? How do I tell deltachat to indicate support for that feature? Without those bits, any third party chatmail client is going to just break randomly for users, and nobody on either end will know why.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae There is absolutely a standard for this; usenet and email has had the in reply to header for years. But now we know chatmail doesn't use it, I guess.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae And what if I send a message to another deltachat user on a different server from mine? How should that be handled? Will they refuse it if it's plaintext? What will I get in return, and how do I surface that to my user? I'm certain it's going to be different from how an email client would handle it. Either way, there's no, you know, standards document documenting these kind of implementation requirements for my third party client. And no infrastructure for warning me when they are about to change, so I can let my user's know we're only compliant with chatmail standard version 5, but an update to bring the new features and requirements of chatmail version 8 is coming soon.
2
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae So what about the reply-to email address? What should my mythical interoperable client do with that? Or "on behalf of"? Do I mark large threads with the mailing list headers? Do I specify the msgid my email is in reply to in the headers or not? Are group chats expected to support threads or always be flat? A chatmail client can't be dfully compatible without documented answers to these questions. And the documents that answer those questions are usually, you know, the documents defining the standard.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae You just did. "CC" in deltachat land is "group chat". That's not how a normal email client uses it.
1
0
1
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae But my client connects to the servers. If they make a change it's going to just break my client without notice. That's a change that needs to be reflected by a new version of some standards document, somewhere.
1
0
1
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae And that's documented where? Not in the RFCs, certainly. Deltachat has changed the semantic meaning of certain fields, and thus how a deltachat interoperable client must present them to users in order to limit confusion and achieve feature parody. There's "What CC means in deltachat land" and "What CC means in email". From a UI and UX and feature compatibility perspective those are critical differences.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae And when this changed, how were the authors of third party clients notified? Was there an open discussion period at a standards committee or a request for comment? No, because the assumption is that everyone should just use libdeltachat. That's not how open standards work.
1
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae If someone cannot write a fully interoperable client, without examination of deltachat code, it's not an open standard. It's just a reference implementation.
1
0
1
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae Because the only way to find out all the implementation decisions deltachat has made is to examine the code. They're "based on" the standards they list, not compliant with them. If I write a core just with those standards as written, It's not going to work correctly with the deltachat app.
1
0
1
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae I'm glad you know this stuff. Wake me up when there are multiple independent chatmail implementations that I can pick from, and what I decide to use is completely transparent to the people I'm chatting with. Until then I'm just not interested in getting my friends and lovers to switch to something that could be ripped away from me at any second, because deltachat decided it didn't want to do an RPC API anymore, and everyone should just shut up and use their client.
0
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae If I don't like the c# library I'm using to build XMPP, I can rip it out and pick another one. There are like 6 to choose from. If they disable an API I needed, I can build it myself, or use a different library. Those are not options with deltachat.
2
0
0
0
User avatar
🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca
3mo
@feld @jae That's what we thought with Twitter and Reddit. Then they discontinued the API's. Those are just two recent examples of something that has happened dozens of times in the last 25 years. Slack discontinuing IRC is another. If I depend on an API that could be taken away at any moment, I have nothing. If there are no competing and interoperable implementations of the standard, you're just at the whims of the owner of the one true version.
2
0
0
0