jdev - 2026-01-04

> <debacle> > macro, alexkurisu Maybe BombusMod is very old and just not compatible with current TLS? > If so, you could setup your own instance without or with very old TLS, too, but that would be extremely insecure. It's not the midlet's issue, it's platform issue to support TLS versions, ciphers and certificates. ↺

> <macro> > The problem is that I can't even log in properly. I think I'll end up creating my own XMPP client. The issue is that I don't know how to program, I don't know how XMPP works, and I don't know anything about making programs for Symbian or J2ME. I'm quite sure you won't accomplish it with this attitude. Feel free to stuff the whole BouncyCastle into the midlet itself so it would support relatively modern ciphers. And even that would theoretically help to support TLS only up to 1.2; 1.3 requires a more low-level access to sockets than midlets have. ↺

Okay, I was just asking for information to see if anyone knew anything or could tell me where to start. Symbian, through patches, is compatible with TLS 1.3, if I'm not mistaken. I already have the patches installed. The problem is that, literally, none of the J2ME-based XMPP client applications can log in. I only found one client called ICQMobile, which is a .sis file, a native Symbian file. That one does work, but obviously it's not compatible with OMEMO. My point is to learn how feasible it is and what I could learn to try to make my own client with OMEMO support for this device I have. I just want some documentation because I'm having a little trouble understanding the XMPP website; I get lost in the organization. Assuming there are people here who know about this, I want to know where I could start. I don't want anyone to do the work for me; I'll figure it out myself.

What language / tech stack do you want to work in?

> <moparisthebest> > xmpp-proxy ran somewhere, possibly even on that phone itself, would give you a plaintext port to connect to and still connect securely to your modern XMPP server No need for specialized xmpp-proxy, I use stunnel4 to connect to servers which enforce TLS, with just three lines of config. BombusMod supports specifying a different server than the JID server, and Jimm Aspro doesn't, sadly. While BombusMod supports only one account at time enabled, and Jimm Aspro supports multiple. ↺

> <singpolyma> > What language / tech stack do you want to work in? Lol, there's no much options for Symbian than restricted C++ and J2ME. ↺

How restricted is the c++? Borogove.dev is an SDK I'm working on torke developing new clients easier. It has a C binding right now but the code inside that technically contains c++. Maybe an option. There will be a JVM target eventually but not yet

> <macro> > Okay, I was just asking for information to see if anyone knew anything or could tell me where to start. Symbian, through patches, is compatible with TLS 1.3, if I'm not mistaken. I already have the patches installed. The problem is that, literally, none of the J2ME-based XMPP client applications can log in. I only found one client called ICQMobile, which is a .sis file, a native Symbian file. That one does work, but obviously it's not compatible with OMEMO. My point is to learn how feasible it is and what I could learn to try to make my own client with OMEMO support for this device I have. I just want some documentation because I'm having a little trouble understanding the XMPP website; I get lost in the organization. Assuming there are people here who know about this, I want to know where I could start. I don't want anyone to do the work for me; I'll figure it out myself. At this moment you need to set up your own XMPP server first, it would be enormously harder to investigate issues with a 3rd party one. At first it makes sense to capture the client's traffic at the side of your server to find out where is the connection torn down. ↺

> <singpolyma> > How restricted is the c++? Borogove.dev is an SDK I'm working on torke developing new clients easier. It has a C binding right now but the code inside that technically contains c++. Maybe an option. There will be a JVM target eventually but not yet I recall some Symbian-specific memory management restrictions which make native programming for it much harder than for other platforms, even with high-level libraries like Qt. ↺

Hmm. Interesting

> What language / tech stack do you want to work in? > Lol, there's no much options for Symbian than restricted C++ and J2ME. Well, the truth is, I apparently have no other option than to program in Symbian C++. While J2ME is more appealing to me for some reasons, such as making it easier to port to other phones from the same era, the system's limitations practically force me to work in Symbian C++. And let me clarify, this C++ is different, so I have to study C++ and also figure out what makes it different from standard C++. I know that OpenC pips and adaptations to the POSIX standard exist, but these are not complete and don't allow full use of the device. Those missing functions might not be necessary in my project, but I'm quite doubtful if it's even worth it.

I assume they have their own TLS stack also one must use or similar?

Maybe best to start lower level with libstrophe and get that working first. It has modular TLS stack support at least

> How restricted is the c++? Borogove.dev is an SDK I'm working on torke developing new clients easier. It has a C binding right now but the code inside that technically contains c++. Maybe an option. There will be a JVM target eventually but not yet My understanding is that Symbian's C++ simply works differently from standard C++, so many instructions are done differently, for some reason, so... if I can use that SDK I would love to, but I have a feeling that won't be the case, at least not without a couple of adaptations (basically rewriting half the code).

> At this moment you need to set up your own XMPP server first, it would be enormously harder to investigate issues with a 3rd party one. > At first it makes sense to capture the client's traffic at the side of your server to find out where is the connection torn down. Okay, I'll look into how to make my own server. It's something I was going to do sooner rather than later anyway. I have a Raspberry Pi intended for this kind of thing, made to provide service and support for some things in my home, so it seems like a good step.

> I recall some Symbian-specific memory management restrictions which make native programming for it much harder than for other platforms, even with high-level libraries like Qt. Being in a Symbian group, very few people have recommended Qt to me. In fact, they've told me that you lose more than you gain, and that it's not worth it, or so they've said. Honestly, I don't know much about it; I've never worked with Qt.

> Maybe best to start lower level with libstrophe and get that working first. It has modular TLS stack support at least I don't really know much about it, to be honest. I installed the modern TLS patches just because... I thought I'd need them, but technically the system has modern TLS embedded in it; it's not something external or modular like the Opera browser could do.

If there's even a chance qt stuff works it can't be that dramatically off standard. I'd suggest to start with trying to port libstrophe since it's low level and all standard C so the least to port.

In fact, Qt's C++ libraries are different from Symbian's own C++, so as I understand it, they are different compilers. Qt in Symbian is self-regulating or something like that. It doesn't work with the same C++.

If that's even possible then, again, I wouldn't be too worried.

Best thing is to start trying a port and see what you run into. Then you'll have a better idea of how much work it is

I was planning to study standard C++, try to make a prototype, then attempt to port it to Symbian and try to fix all the compilation errors I encounter, feeling even more miserable than when I finished. But anything for the greater good (for me and four other weirdos).

you still run a symbian device? Or are new devices still being created?

macro, starting from scratch is a significant effort - several times more so without previous experience. If Symbian C++ is so majorly different from the standard then it's not C++, but more likely it has some small annoying differences, so recompiling an existing library and just fixing those errors will be much easier (and you actually stand a change of getting something usable before the end of the century)

i hate to be that guy who jumps in and asks irrelevant questions like 'why symbian', but i am really interested, perhaps some context did not sync to me... i have heard there's a community that tries to keep symbian alive and i don't know even if it works on modern devices or it is possible to install newer symbian on older devices?

folks since i started talking, i wanted to tell that i am working on, and actually i have a working version of my bonjour fork, that replaced all mdns related stuff with xml stanzas i borrowed from regular xmpp, and i chat p2p over yggdrasil network with it.

by saying bonjour fork i meant pidgin's bonjour plugin fork.

at first i wrote an mdns faker that would allow to use plain bonjour with yggdrasil.

however it soon became clear it wasn't a best way:

no statuses, no avatars, no file transfers, i could only make messaging to work with bonjour over yggdrasil with my mdns faker.

and it was not a beautiful solution, i had to poke a remote bonjour port to make sure the other party is available. bonjour doesn't need it, it uses mdns to know if the other party is available, and can also know if away (no do not disturb by the way).

so i gave that up, forked bonjour plugin, it was a part of pidgin, so i first made sure i can build it out of pidgin source tree.

then i gradually was adding features: adding a contact as nick@ipv6, messaging, statuses (including do not disturb and status lines), file transfers, typing notifications.

yggdrasil makes e2e encryption by itself on the lower layer.

yes also avatars work.

since i have a working pidgin plugin, i also wrote a pascal library and cli client that can chat with my pidgin plugin.

now i have it i can write a crossplatform standalone gui client in pascal.

https://github.com/norayr/barev https://github.com/norayr/libbarev

sorry for github, will migrate one day.

if you have any questions or suggestions feel free to ask. some people from yggdrasil community already enjoy using it. and were very helpful with testing.

the other direction people from yggdrasil experiment with in setting up xmpp servers with ipv6 instead of domain, and self generated certificates, but this way is very hard.

barev is just run, add contacts and start chatting. however no mucs of course.

> you still run a symbian device? Or are new devices still being created? I think they're still manufactured in some parts of the world, especially in the East, Asia, and far eastern Europe. But that's not my case; I use a Nokia N95 from 2007. I'm just interested.

I used to run symbian devices. Was very impressed with what they could do. If only it hadn't been so hard to set up a good development environment.

(and access to the development information)

> macro, starting from scratch is a significant effort - several times more so without previous experience. If Symbian C++ is so majorly different from the standard then it's not C++, but more likely it has some small annoying differences, so recompiling an existing library and just fixing those errors will be much easier (and you actually stand a change of getting something usable before the end of the century) From what I understand, it's not that different, but keep one thing in mind: if you change even a single thing in the language's "grammar," you have to edit a lot of code. The differences might not be too many, but having to edit the code makes it a much more laborious task. And yes, I'll probably have at least a prototype by the end of this century.

> I used to run symbian devices. Was very impressed with what they could do. If only it hadn't been so hard to set up a good development environment. I used to run symbian devices. Was very impressed with what they could do. If only it hadn't been so hard to set up a good development environment.