close
  • chevron_right

    Newsletter: Multilingual Transcriptions and Better Voicemail Greetings

    Stephen Paul Weber · Wednesday, 27 July - 17:30 · 2 minutes

Hi everyone!

Welcome to the latest edition of your pseudo-monthly JMP update!

In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client.  Among other things, JMP has these features: Your phone number on every device; Multiple phone numbers, one app; Free as in Freedom; Share one number with multiple people.

As foreshadowed last month, the new voicemail transcription engine is now live for all customers who have transcription enabled (which it is by default).  This should improve speed and accuracy, and bring support for many more languages to the system.  Let us know if you notice any issues with the new transcriptions.

From the beginning of the voicemail system we have supported a default text-to-speech greeting if a custom one is not set.  The name used in this greeting is sourced from the customer’s legacy vCard if they have one set up.  We now also support modern vCard4 and PEP Nickname specifications to get this data, which should result in it working for many more people with many more clients.  Check the voicemail FAQ for details.

Many new JMP customers are also new to Jabber in general, and so our signup process usually suggests one or more free-to-use volunteer-run Jabber services that one can sign up with to get a working Jabber ID.  These services are best-effort by volunteers, and this month one of the ones most popular with our customers experienced an extended outage.  The best protection you can have against any kind of outage at your Jabber service is to have your Jabber ID be attached to a DNS name you control.  With or without your own name, we also include the option for any JMP customer to get an instance hosted by Snikket at no extra charge.  Please contact support if you have any questions about this.

To learn what’s happening with JMP between newsletters, here are some ways you can find out:

Thanks for reading and have a wonderful rest of your week!

  • chevron_right

    Newsletter: Command UI and Better Transcriptions Coming Soon

    Stephen Paul Weber · Wednesday, 29 June - 18:00 · 1 minute

Hi everyone!

Welcome to the latest edition of your pseudo-monthly JMP update!

In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client.  Among other things, JMP has these features: Your phone number on every device; Multiple phone numbers, one app; Free as in Freedom; Share one number with multiple people.

This month the team has been hard at work on a new major feature for Cheogram Android: the command UI.  This feature will get rid of the need to configure your account with a clunky chat bot on mobile, replacing it with a fit-for-purpose native UI that can be viewed under the cheogram.com contact.  And because we are implementing it using only open standards, the UI will also work for other command-using entities out there.  The feature is not quite ready for first release, but if you want to come test a pre-release just drop by the chatroom (see below for how to get to the chatroom).

Almost since the beginning of JMP one of the favourite features has been our voicemail.  Reading your voicemails instead of having to “dial in” somewhere and listen to them is a real advantage for many users.  However, the transcription is far from perfect, sometimes being slow and completely missing support for any language other than English.  We are now testing an alternative engine with anyone who is interested, this new engine gets you the transcription faster and supports dozens of languages.  Come by the chatroom if you want to help test this out before we roll it out as a full replacement.

To learn what’s happening with JMP between newsletters, here are some ways you can find out:

Thanks for reading and have a wonderful rest of your week!

  • chevron_right

    Newsletter: Togethr, SMS-only Ports, Snikket Hosting

    Stephen Paul Weber · Tuesday, 31 May - 13:30 · 1 minute

Hi everyone!

Welcome to the latest edition of your pseudo-monthly JMP update!

In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client.  Among other things, JMP has these features: Your phone number on every device; Multiple phone numbers, one app; Free as in Freedom; Share one number with multiple people.

This month our team launched a new product to help people looking to take even more control of their digital life by hosting their own social media instance.  Read about Togethr, what it is today, and a glimpse of our future plans.

JMP now supports SMS-only ports.  Landlines and most numbers with VoIP providers (but not numbers with most mobile carriers) are eligible to have JMP provide SMS/MMS messaging services for the number, while voice and other services would remain with the current carrier.  This feature is in Alpha, contact support if you are interested.

This month also saw the release of Cheogram Android 2.10.6-1.  This version merges in the latest upstream release of Conversations, as well as fixes for the contacts integration and playback for some media types (most notably 3GPP videos).

Finally, our integration with Snikket hosting is coming along.  For all of this year JMP customers have been able to get into the Snikket hosting beta with the promise of never having to pay for the JMP-using Jabber IDs they host there.  Now, JMP customers no longer need to contact Snikket staff to be put into the regular beta queue.  Contact JMP support and we can set you up with a Snikket instance directly.  We will continue to work on this integration until someday it becomes a fully self-serve part of signup.

To learn what’s happening with JMP between newsletters, here are some ways you can find out:

Thanks for reading and have a wonderful rest of your week!

  • wifi_tethering open_in_new

    This post is public

    blog.jmp.chat /b/may-newsletter-2022

  • Pictures 1 image

  • visibility
  • favorite

    4 Like

    Angelica, debacle, Morgan McMillian, carl

  • 1 Comments

  • 3 June carl

    Hi
    Thanks for your contribution.
    Hope you keep writing here and stay here.

    Movim is a great story.

  • chevron_right

    Togethr: Soprani.ca Social

    Stephen Paul Weber · Wednesday, 11 May - 20:45 · 2 minutes

Last week we launched a sister product from the same team that brings you JMP: Togethr.  Why are we launching a second product?  Why now?  What does this have to do with the mission of JMP in particular, or the Sopranica project in general?

Togethr is a managed hosting platform for small Fediverse instances.  It is powered by the ActivityPub protocol that powers Mastodon, PeerTube, and so many others.  While there are several social networking solutions that build on XMPP (just like JMP does), and indeed we use one for this blog, we chose to go with something else for Togethr.  Does that mean we don’t have hope for XMPP in the social space?  No, rather it is an admission that the largest network for people to interact with in this way exists on ActivityPub-compatible software, and people need a solution they can use today.

As it grows, Togethr gives us the “skin in the game” motivation to bridge these worlds.  We are not the only ones interested in bridging the XMPP and ActivityPub worlds together, in fact the Libervia project is currently working on a grant to produce a first version of a gateway, that should be generally usable later this year.  We hope to eventually roll out an update that makes every Togethr instance seamlessly be both ActivityPub and XMPP without anyone needing to change their address.

Why not wait until “everything is ready” to go live with XMPP and ActivityPub at the same time?  Well, people need a solution.  Many people fleeing silos or otherwise being attracted to federated social networking find that self-hosting is too complicated, or they just don’t have the time to dedicate to it.  Many of these people end up creating an account on a giant volunteer-run instance, joining yet another silo (albeit a nicely federated one) run by admins they don’t know with financial and mental pressures they cannot understand.

Togethr gives people looking to federate their digital social networking experience full control without requiring systems administration knowledge or time.  Our team not only keeps the instance running, but provides support for users who may not be familiar with the software or the fediverse in general and need help getting everything set up.  However, there is no lock-in and people can easily move to another host or self-hosting at any time.  For example, if someone got an instance example.party and created the user person they would have address person@example.party just like you would expect on any Fediverse instance.  However, since they control the domain they could move to a different host or self-host, point the domain at the new instance, copy over their data, and no one has to “follow me at my new address”, everything just keeps working.

While we believe that single-user instances are the pinnacle of federation, Togethr does not limit the way people want to use it.  People may have family or friends they want to share posts with, who might not be motivated to join the Fediverse but will accept a personal invitation.  So every Togethr instance allows the customer to invite whoever they would like to join them on the instance, in order to smooth the onboarding for friends and family.  We hope that this can provide an option for people looking to take control over more of their digital life.

  • chevron_right

    Newsletter: New Staff, New Commands

    Stephen Paul Weber · Wednesday, 27 April - 21:00 · 1 minute

Hi everyone!

Welcome to the latest edition of your pseudo-monthly JMP update!

In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client.  Among other things, JMP has these features: Your phone number on every device; Multiple phone numbers, one app; Free as in Freedom; Share one number with multiple people.

The JMP team is growing.  This month we added root, whom many of you will know from the chatroom.  root has been a valuable and helpful member of the community for quite some time, and we are pleased to add them to the team.  They will be primarily helping with support and documentation, but also with, let’s face it, everything else.

The account settings bot has a new command for listing recent financial transactions.  You can use this command to check on your auto top-ups, recent charges for phone calls, rewards for referrals, etc.  There is now also a command for changing your Jabber ID, so if you find yourself in a situation where you are changing for any reason you can do that yourself without waiting for support to do it manually.

This month also saw the release of Cheogram Android 2.10.5-2.  This version has numerous bug fixes for crashes and other edge cases and is based on the latest upstream code which includes a security fix, so be sure to update!  Support for TOR and extended connection settings has also been fixed, a new darker theme added, and UI tweaks to recognize that messages are often encrypted with TLS.

To learn what’s happening with JMP between newsletters, here are some ways you can find out:

Thanks for reading and have a wonderful rest of your week!

  • chevron_right

    Computing International Call Rates with a Trie

    Stephen Paul Weber · Wednesday, 13 April - 05:30 · 4 minutes

A few months ago we launched International calling with JMP.  One of the big tasks leading up to this launch was computing the rate card: that is, how much calls to different destinations would cost per minute.  While there are many countries in the world, there are even more calling destinations.  Our main carrier partner for this feature lists no fewer than 59881 unique phone number prefixes in the rates they charge us.  This list is, quite frankly, incomprehensible.  One can use it to compute the cost of a call to a particular number, but it gives no confidence about the cost of calls in general.  Many items on this list are similar, and so I set out to create a better list.

My first attempt was a simple one-pass algorithm.  This would record each prefix with its price and then if a longer prefix with a different price were discovered it would add that as well.  This removes the most obvious effectively-duplicate data, but still left a very large list.  I added our markup and various rounding rules (since increments of whole cents are easier to understand in most cases anyway, for example) which did cut down a bit further, but it became clear that the one-pass was not going to be sufficient.  Consider:

  1. +00 at $0.01
  2. +0010 at $0.02
  3. +0011 at $0.02
  4. +0012 at $0.02
  5. +0013 at $0.02
  6. +0014 at $0.02
  7. +0015 at $0.02
  8. +0016 at $0.02
  9. +0017 at $0.02
  10. +0018 at $0.02
  11. +0019 at $0.02

There are many sets of prefixes that look like this in the data.  Of course the right answer here is that +001 is $0.02, which is much easier to understand than this list, but the algorithm cannot know that until it has seen all 10 overlapping prefixes.  Even worse:

  1. +00 at $0.01
  2. +0010 at $0.02
  3. +0011 at $0.02
  4. +0012 at $0.02
  5. +0013 at $0.02
  6. +0014 at $0.02
  7. +0015 at $0.03
  8. +0016 at $0.02
  9. +0017 at $0.02
  10. +0018 at $0.02
  11. +0019 at $0.02

From this input we would like:

  1. +00 at $0.01
  2. +001 at $0.02
  3. +0015 at $0.03

So just checking if the prefixes we have so far are a fully-overlapped set is not enough.  Well, no problem, it’s not that much data, perhaps I can implement a brute-force approach and be done with it.

Brute force is very slow.  On this data it completed, but as I found I kept wanting to tweak rounding rules and other parts of the overlap detection the speed became really problematic.  So I was searching for a non-bruteforce way that would be optimal across all prefixes and fast enough to re-run often in order to play with the effects of rounding rules.

Trie

As I was discussing the problem with a co-worker, trying to speed up lookups we were thinking about trees.  Maybe a tree where traversal to the next level was determined by the next digit in the prefix?  As we explored what this would look like, it became obvious that we were inventing a Trie.  So I grabbed a gem and started monkeypatching things.

Most Trie implementations are about answering yes/no questions and don’t store anything but the prefix in the tree.  I wanted to be able to “look down” from any node in the tree to see if the data was overlapping, and so storing rates right in the nodes seemed useful:

def add_with(chars, rate)
    if chars.empty? # leaf node for this prefix
        @rate = rate
        terminal!
    else
        add_to_children_tree_with(chars, rate)
    end
end

But sometimes we have a level that doesn’t have a rate, so we need to compute its rate from the majority-same rate of its children:

def rate
    # This level has a known rate already
    return @rate if @rate

    groups =
        children_tree.each_value.to_a         # Immediate children
        .select { |x| x.rate }                # That have a rate
        .combination(2)                       # Pairwise combinations
        .select { |(x, y)| x.rate == y.rate } # That are the same
        .group_by { |x| x.first.rate }        # Group by rate
    unless groups.empty?
        # Whichever rate has the most entries in the children is our rate
        @rate = groups.max_by { |(_, v)| v.length }.first
        return @rate
    end

    # No rate here or below
    nil
end

This algorithm is naturally recursive on the tree, so even if the immediate children don’t have a rate they will compute from their children, etc.  And finally a traversal to turn this all back into the flat list we want to store:

def each
    if rate
        # Find the rate of our parent in the tree,
        # possibly computed in part by asking us
        up = parent
        while up
            break if up.rate
            up = up.parent
        end

        # Add our prefix and rate to the list unless parent has it covered
        yield [to_s, rate] unless up&.rate == rate
    end

    # Add rates from children also
    children_tree.each_value do |child|
        child.each { |x| yield x }
    end
end

This (with rounding rules, etc) cut the list from our original of 59881 down to 4818.  You can browse the result.  It’s not as short as I was hoping for, but many destinations are manageable now, and thanks to a little bit of Computer Science we can tweak it in the future and just rerun this quick script.

  • chevron_right

    Newsletter: Cheogram Android Release, Matrix Alpha

    Stephen Paul Weber · Tuesday, 29 March - 03:00 · 2 minutes

Hi everyone!

Welcome to the latest edition of your pseudo-monthly JMP update!

In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client.  Among other things, JMP has these features: Your phone number on every device; Multiple phone numbers, one app; Free as in Freedom; Share one number with multiple people.

This month marks the first release of the Cheogram Android app we have been sponsoring.  This app is a fork of the excellent Conversations, and will stay close to upstream going forward.  Some of the improvements relevant to JMP users include:

  • Add contacts without typing @cheogram.com
  • Integrate with the native Android Phone app (optional)
  • Address book integration
  • Messages with both media and text, including animated media
  • Unobtrusive display of subject lines, where present (such as on voicemails)
  • Links to known contacts are shown with their name (improves group text UX)
  • Show timestamps for calls
  • Missed call notifications

All of these features have been built in a standards-compliant way and do not rely on anything particular to Cheogram or JMP at all, so they could be reused with other gateways as well.  You can also get the app from F-Droid.

In other news, we’ve heard for some time that some users want to try using JMP from Matrix.  Since we are so big on bidirectional gateways, we have decided to add support for signing up with JMP using a Matrix ID.  This should be considered an alpha test at this time, and most notably voice does not work with the gateway yet so you will need to use SIP (or forwarding) for voice if you use a Matrix ID.  SMS, MMS, and Voicemail will all be delivered to Matrix just as they are to Jabber.  For this we are using the excellent gateway instance at aria-net.org.  To get started, just head to JMP.chat, choose a phone number, and select “I am a Matrix user” on the next page.

To learn what’s happening with JMP between newsletters, here are some ways you can find out:

Thanks for reading and have a wonderful rest of your week!

Art in screenshots is from Pepper & Carrot by David Revoy, CC-BY. Artwork has been modified to crop out sections for avatars and photos, and in some cases add transparency. Use of this artwork does not imply endorsement of this project by the artist.

  • chevron_right

    Why Bidirectional Gateways Matter

    Stephen Paul Weber · Wednesday, 23 February - 04:30 · 3 minutes

A big part of the vision of Sopranica, and Cheogram in particular, is bidirectional gateways.  A bidirectional gateway is one that allows (at a minimum) any user of either protocol to contact any user of the other protocol without creating an account.  This is not possible with all protocols, but works well when both sides are federated.

Simple Example

Take for instance sip.cheogram.com, which is a bidirectional gateway between XMPP and SIP.  Any federated Jabber ID can communicate with any federated SIP URI with no configuration at the gateway.  This is possible because every valid SIP URI is assigned a Jabber ID of the format xmpp:user\40domain.tld@sip.cheogram.com and every Jabber ID is assigned a SIP URI of the format sip:user%40domain.tld@sip.cheogram.com.

Contrast this with irc.cheogram.com, which is not a bidirectional gateway even though IRC is an open protocol, due to the non-federated nature of that protocol.  While every IRC channel and nick is given a Jabber ID, not every Jabber ID can be given a channel or nick on every IRC network out there, and even to do it on a single network would require creating many connections or a special peering arrangement.  Using the Jabber ID assigned to an IRC channel may require registering a nick with that IRC network and configuring the associated password at the gateway.  It works well enough, and is quite useful, but it’s not bidirectional.

User Experience

One of the big advantages of a bidirectional gateway is the seamless user experience for those who know the gateway exists.  Instead of asking “is this room bridged to protocol X” or “do you also have an address on protocol Y” the existance of the bridge is sufficient to know that, yes, with no extra setup by either party, communication will be possible.  One does not need to convince users to switch to the favored protocol, or bend by creating an identity with the other’s favored protocol, but simply to add the other party directly.  Users with Jabber IDs can advertise how they may be contacted via SIP, SMTP, Matrix, SMS, and more without the other party thinking anything more than “this address looks a bit long”.

Raising the Whole Network with Chaining

Because a high-quality bidirectional gateway effectively makes one network out of two networks, any service or gateway added to either network can be used from both sides.  Thus, Matrix, SMTP, or even SMS users can get phone numbers from JMP.  Even further than that, a Matrix user could advertise an SMTP or SIP contact address using the Cheogram gateways, all without any SMTP or SIP gateway needing to exist for Matrix at all.

Stable Addresses

If someone is going to give out an address that goes via a gateway, they need confidence that this address will not need to be changed.  So long as their main address on their preferred protocol remains the same, so should their address on other protocols.  This requires a stable DNS name with gateways that are open to anyone, free of charge.  That is the vision behind Cheogram, an infrastructure project inside of Sopranica to maintain stable addressing for bidirectional gateways.

Conclusion

Obviously there is still lots of work to do. Most of the gateways mentioned in this post are missing important features they could have in order to facilitate more seamless communication.  Clients of every protocol can gain features to make using a bidirectional gateway a more obvious choice for users.  Unique use cases need more testing to find where the rough edges are.  Cheogram infrastructure is supported in part by JMP, but can always use financialsupport.  Together we can help people connect to all their contacts.  Come join us.