I guess the functionality isn't better (let's be honest, it's probably worse) than the proprietary alternatives, but for now the family is happy with it and I feel good about the extra privacy / lack of advertising / etc.
Really appreciate all the people that put in the work to make this possible. Great work Dino team.
Curious about this, since it seems to imply your kids use Linux desktops. How has that worked out?
My daughter recently has started to do more artwork on the computer (she's using a Wacom tablet with Krita). I don't know much about that world. Maybe there are way better tools and she'll want to switch to one of those in the future? (Is that an ipad? some Adobe software?). I figure as they get older and develop their own opinions we can revisit what types of computers/software they use, but for now things are going good.
No issues with it. The (IMO, kind of sad) reality is that almost everything she needs to interact with is either web or cross-platform electron. The only real exception here is Zoom, which has a native linux client. She doesn't really need to understand much detail to use the machine.
She used GNOME before she ever saw Windows. We switched school systems and now she has a Windows laptop at school and her Linux laptop here, which she switches back and forth between without any trouble.
The only usability quirk is the LUKS FDE decryption phase, where she has to enter in her password before the system starts. There's no GUI and bad feedback on when she's typing, so it's confusing. But she understands what to do now and usually has no trouble (you might be surprised at how flexible kids are).
My partner and family use https://quicksy.im/ which is an XMPP client that uses their phone number as username, to give it a "convenient as WhatsApp/Signal" feel.
I run the mobile UI branch https://github.com/dino/dino/tree/feature/handy on my Pinephone.
Any general feedback on the pinephone? Is it your main smartphone?
I haven't seen A/V calls working, but I know compatibility is being worked on. Audio calls will work before video calls.
The Pinephone is a breath of fresh air, but it's not yet ready for casual use by techies.
Pinephone is too slow to be my main phone. I'm looking forward to Pinephone Pro, which is fast enough, being able to reliably sleep.
Anyways, nice milestone for Dino! I still gotta try out the solution one day.
I don't mean to be a downer, but if you want to reach a lot of people with your amazing software (not saying that you have to, but it seems like one of the intentions of the project), it's a good idea to get them where they already are.
Side note 1: Vala/GTK could be an amazing app development platform if the cross-OS story was clearly (it can absolutely cover desktop OSes and I think even phones, but how to do it isn't very clear and most GTK apps don't).
Side note 2: Dino seems to be co-developed by the guy who makes microG, another great piece of software (replaces Google services on Android).
Side note 3: It would be great to see an XMPP revival. Quality clients like Dino are a key part to this. An important part for that may be another standardization effort with a low number of groups of clearly defined XEPs to support some functionality (a huge problem appears to be the sheer number and fragmentation of XEPs).
The XMPP Standards Foundation publishes a document once a year stating a set that decent XMPP clients and servers should implement. The current one, https://xmpp.org/extensions/xep-0459.html even has a specific section on calling (it doesn't cover group calls yet).
Here are Dino builds for Windows.[0]
Freedesktop folks should just standardize on Cocoa. With sufficient momentum, Windows would follow.
If you use Jabber today, who are you talking to and on what server(s)?
It seems to be a good fit for families. Or rather, families are a good fit for any sane, sustainable technology. Long span of time, lots of mutual transparency, plenty of in-group communication inside and outside the chat technology.
No problems characteristic for big-tech (account seizures, hardware platform restrictions). No problems characteristic for free-for-all public servers (spam, vandalism).
XMPP for me is mostly internet friends. It's quite popular on the fediverse (they also happen to commonly dislike Matrix, although many are on both like me). Lots of people who are into technology and anime, basically.
I've noticed most free software projects don't have an XMPP room unless they are literally XMPP projects like Gajim and Dino. Pine64 (as well as many other places) will have a bridge between IRC and Matrix, but I've only seen one or two IRC channels that also bridge XMPP that I can remember. Many people aren't even really aware of it. I don't know the actual stats, but it often feels like XMPP is actually less popular than IRC these days.
I run my own server (any 5 bucks VPS can do), but there is a large number of public servers that also work good. Make sure to pick one with a good ranking at https://compliance.conversations.im/
(I will add that Jitsi Meet kind of counts as Jabber use, although not in the traditional sense)
I imagine this means the 2+ clients use XMPP to negotiate direct connections to one another that are better suited for audio/video streaming.
In Dino (Desktop) window click on [+] in left-top corner on app title bar, and then input channel to join as next:
chat@dino.im
N.B. Here is offical announcment of Dino 0.3 release thread on Mastodon.[0]
From our testing, Whatsapp is one of the worst. Zoom is in between. Hangouts is usually decent. But again, nowhere near bluray quality.
I think Discord was similarly good but... Discord just isn't what I'm going to voice call family on... realistically ever.
Conference calls with a central server are particularly suspectible to "lowest common denominator" issues.
Also to consider: where does the connection flow through? if you're both going through Google/Amazon servers (SFU, etc), it's quite possible your ISP will provide a route with a decent bandwidth. It's also quite possible if you establish a direct P2P link or through a route your ISP considers less important, they'll slow it down or simply oversubscribe this route.
Latency and non-terminated encryption (end-to-end, not point-to-point) is great, and for calls with 3 or fewer peers the stability is fine. More peers than that and you probably want a media router in the mix, which adds some latency (all the calls have to route through a central server) and the server typically has done termination of the encrypted call streams as it does its routing.
Dino already supports some kind of "double encryption", where even if DTLS-SRTP is terminated at a media routig or bridging server, there is another SRTP encryption layer. This allows for end-to-end encryption even when DTLS-SRTP is terminated by a server for WebRTC compliance (as WebRTC requires to encrypt using DTLS-SRTP even if transported media was already encrypted through other means).
[1] https://stackoverflow.com/questions/10202143/what-is-the-dif...
CMake Error at /opt/homebrew/Cellar/cmake/3.22.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Soup (missing: Soup_LIBRARY)
Call Stack (most recent call first):
/opt/homebrew/Cellar/cmake/3.22.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
cmake/FindSoup.cmake:29 (find_package_handle_standard_args)
cmake/MultiFind.cmake:20 (find_package)
plugins/http-files/CMakeLists.txt:1 (find_packages)
i have been mulling the switch to a selfhosted thing for some time now but i need something that can run on low resources but isnt overly complicated
The client setup in XMPP and Matrix seem to have the same usual steps (username and password). No big differences here, other than Element defaults to matrix.org to create an account (which contributes to centralization).
I'd say that XMPP clients are generally better than matrix's ones. Maybe because matrix is an immature and younger protocol, but Element seems to be the only client that implements everything and UI is confusing and it's electron.
And a personal preference, I like using my GPG keys to encrypt my conversations when possible in XMPP. This wouldn't be possible in matrix.
IMHO, the basic prosody setup is a bit simpler, but with the "extra" configuration such as retention policies, they're equal in setup effort.
On the other hand, prosody is an order of magnitute easier to maintain and administer. synapse is too brittle, and its not uncommon to use gigabytes of memory, while prosody's resource usage is barely noticible.
On the occasions that I wanted to look under the hood and skim the code, I felt more confortable understanding and hacking on prosody.
Overall, I found synapse to be needlessly complex and big. I don't know if that's because it's the first implementation and it accumulated a bunch of legacy code, or that's something that comes with Matrix itself.
could we say, define 2-3 days attachment retention rule to save on space?
[1] https://en.wikipedia.org/wiki/Vala_(programming_language)
"Peer-to-peer calls require more bandwidth than calls routed through a server and are thus not suited for a large number of participants. In the future, we plan to also develop calls via a forwarding server to solve resource issues on the client side and to allow for calls with more participants."
User B: Is user C's stream dead for anyone else? User A: I see user C. User C: Sorry, what? I'm right here.
Honestly, other than a 1-1 chat, I can't think of a situation where p2p is worthwhile. Even then, it's almost always better to use an SFU.
Both XMPP and Matrix servers can also be run on your own device (p2p): in XMPP world it's more common for ZeroConf LAN chat (to chat with other peers/servers in the LAN, not internet servers), while Matrix project is spending some efforts on Pinecone based on libp2p/yggdrasil to punch through NAT and (if it succeeds) offer proper P2P internet-wide. They have different trade-offs: XMPP protocol is more lightweight but less consistent about eventual delivery of messages when some servers can be offline at any given moment (it was initially designed as a live message-passing protocol).