# Announcing App Authentication & WebTransceiver Retirement: Proposal Review

**URL:** <https://community.allstarlink.org/t/announcing-app-authentication-webtransceiver-retirement-proposal-review/25025>\
**Category:** AllStarLink\
**Created:** [September 25, 2026, 8:58pm UTC](https://community.allstarlink.org/t/announcing-app-authentication-webtransceiver-retirement-proposal-review/25025 "2026-09-25T20:58:33Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![N8EI](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n8ei/32/4254_2.png) [@N8EI](https://community.allstarlink.org/u/N8EI)\
**Post date:** [September 25, 2026, 8:58pm UTC](https://community.allstarlink.org/t/announcing-app-authentication-webtransceiver-retirement-proposal-review/25025/1 "2026-09-25T20:58:33Z")

</div>

Years ago, the [allstarlink.org](http://allstarlink.org) website hosted a Java Applet communicator to interoperate with standard nodes on the AllStarLink Network. In the intervening years, the authentication method developed for this applet named "Web Transceiver" became the de facto standard for authenticating mobile and desktop applications to the AllStarLink network. These terms are used today: "WebTransceiver mode", "WT auth", "WT Mode", etc. However this method has numerous flaws and must be replaced.

WebTransceiver is what applications such as Repeater Phone, DVSwitch, etc. all use on mobile devices or apps such as Transceive or QSOone - and used _for authentication_. Note this does not mean that these applications will be going away, only that they will be updated to the new App Authentication ("AA") model at some point before the old WT authentication is removed. It is also important to note that "WebTransceiver" is not a separate "mode" for AllStarLink connections - they all use IAX2 - only that how the connection authenticates is different (i.e. "nodeless").

Standard **ASL002** has been developed to replace deprecate and replace "WebTransceiver" authentication to modernize the process of authenticating users. The document can be found here:

[https://github.com/AllStarLink/Standards/blob/main/ASL002-App\_Authentication.md](https://github.com/AllStarLink/Standards/blob/main/ASL002-App_Authentication.md)

This document is being made available now for a "fatal flaw" review while the new API is in development. (See [this description](https://github.com/AllStarLink/Standards/blob/main/README.md#fatal-flaws-review) for what this is.) This topic in Community can be used to ask any clarifying questions. This document will be open for fatal flaw review through October 2nd.

Of particular note, the standard includes the transition mechanisms and deprecation timelines for "Web Transceiver". Currently the expected implementation date is somewhere around the first or second week of November but a formal date will be announced in the coming weeks. I expect the API to be available for testing in mid- to late-October.

Thanks.  
Jason

---

<div class="post-metadata">

**Author:** ![W2DB](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/57b2e6/32.png) [@W2DB](https://community.allstarlink.org/u/W2DB)\
**Post date:** [September 27, 2026, 8:01am UTC](https://community.allstarlink.org/t/announcing-app-authentication-webtransceiver-retirement-proposal-review/25025/2 "2026-09-27T08:01:06Z")

</div>

how does this impact pre-ASL3 installations?  
GeorgeC W2DB

---

<div class="post-metadata">

**Author:** ![N8EI](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n8ei/32/4254_2.png) [@N8EI](https://community.allstarlink.org/u/N8EI)\
**Post date:** [September 27, 2026, 12:44pm UTC](https://community.allstarlink.org/t/announcing-app-authentication-webtransceiver-retirement-proposal-review/25025/3 "2026-09-27T12:44:13Z")

</div>

> [@W2DB](#):
>
> how does this impact pre-ASL3 installations?

Pre-ASL3 installs will need to update their `extensions.conf` file if they wish to accept incoming app-based connections by the end of the transistional period.