Frequently Ask Question (FAQ)

This FAQ section is created to provide a better understanding to aTalk users on the application features and observed behavior. This section will continuously be updated as more inputs are feedback from aTalk users.
CONTENT

Account Setup & Login

Enhanced Features

OMEMO Messaging

OTR Messaging

Media Call Communications

User Avatar

General


Account Setup & Login
Does aTalk communicate with all the available xmpp clients in the market? { Content }
By definition, if an xmpp client implementation follows XMPP standards as defined in XEP's spefications, then it should be able to work with aTalk. A list of all the XEP's supported by aTalk can be viewed in the About dialog box on your installed device or the site: atalk-android
aTalk has been verified to work with the following xmpp clients e.g.
[20180526] What information to enter in "Override server setting" when I setup a new account? { Content }
In today advance technology, a physical xmpp machine can actually support multiple virtual domain services/hosts. This service name is usually tag with the user xmpp account e.g. alice@example.org where example.org is usually referred to as service domain or virtual host.
If you leave the Override server option unchecked, aTalk first needs to ensure the specified domain name is reachable, it searches for the actual internet ip address on a Domain Name Server (DNS). On success, aTalk then proceeds to lookup the SRV record from the server which contains the required ip:port information for connection. Connection attempt wil fail if neither of the following conditions is met, and you will need to enable the Override server option:
In the first case, you need to specify the actual physical domain name (FQDN) where the service reside.
For the second case, you need to copy the service/domain name into the Connect Server IP field, so aTalk will not look for SRV record on server, instead drop back to use the resolved internet address for connection.
User may enter either a FQDN hostname or an Internet IP address in the Connect Server IP starting with aTalk version 1.3.1.
[20180818] SSL Certificate Authentication, DNSSEC and DANE Security Implementation for Connection Establishment { Content }
aTalk (v1.3.1) supports the following connection establishment security mode. Please note that both DNSSEC and DANE implementations are still at expermental implementation by miniDNS/smack/aTalk. DNSSEC does not work on server with a self-signed certificate or certificate signed by untrusted root CA's. You may refer to android Seurity Settings for a list of trusted CA certificates.
Plese refer to the following sites for more information:
Do I have to enable IB Registration option when I setup a new account? { Content }
"IB Registration" stands for "In-Band Registration" and is defined in XEP-0077 standard. In general, if an account already has been created and assigned to you by your server administrator, you do not need to enable IBR option during account setup. This is usually not true if you want to register an account on an online free xmpp server. Some server needs you to create an account via their web interface before you can setup the account on your xmpp client. If the server supports IBR, then you can create and register a new user account from within aTalk in one single step. When you setup an account with IBR enabled, aTalk does a pre-check whether the account exist on the server, and proceed with the IBR only if the login failed with exception <not-authorized/>.
A few points to note when doing IBR registration as most server has the following rules set:
Why my first login in sometimes fails when a new account is created? { Content }
Most of the servers today have installed a ssl certificate on their site. The certificate usually are signed with the private key of a trusted certificate authority. The certificate contains the domain name and/or ip address of the server. When you visit the site, this certificate is downloaded and compared against the public keys of all the major certificate authorities; and confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection.
When you setup an account with a new server, aTalk downloads the site certificate and compares against its database. It prompts for manual confirmation if the certificate is new. If you take some time to confirm the certificate before proceed, the server hold time may have expired and the established connection gets disconnected. This is the reason why you need to login a second time.

Enhanced Features
Adding Contact { Content }
In order to protect the privacy of XMPP users, presence information is disclosed only to other entities that a user has approved. When a user has agreed that another entity is allowed to view its presence, the entity is said to have a "subscription" to the user's presence. An entity that has a subscription to a user's presence or to which a user has a presence subscription is called a "contact".
When you add a buddy to your contact list, aTalk actually makes a subscription request to your buddy for his/her approval. In this process, your hosted server routes your subscription request locally if the buddy is on same server; otherwise remotely with connection made to the buddy hosted server via IP derived from your buddy account service name i.e. example.org from "buddy@example.org". If the Fully Qualified Domain Name (DQDN) of your buddy hosted server cannot be derived from his JID account service name, the subscription request process will fail. With the current XMPP standard defined for Presence Subscription, it is therefore not possible to include buddy whom resides on a different server where his/her account JID does not contain the FQDN. You are also unable to send message to your buddy in this case since the message is delivered via server-to-server network connection.
When your buddy client receives the Presence Subscription Request from hosted server, an Authorization Reqeust dialog is launched for hist/her approval. Your buddy may Ignore, Deny or Authrize the request. Reciprocally, a Presence Subscription Request will be reverted for your approval when your buddy approved the request. In the event your buddy chooses to ignore your request; any further re-authorization request from you will not trigger another Authorization Request. However the server will resend the reqeust on your behalf when the buddy has exited and login again. This process continues until user has made a decision either to Deny or Authrize the request.
The "Add Contact" dialog provides the option to categorize your new contact to one of your existing defined groups or a newly created group. You may perform this grouping or moving to another group after the contact has been added. The same option is also available to your buddy when he approves the Presence Subscription Request.
You may also enable the Presence Subscription Approval - auto accept all in the [menu | Settings...]. Under this case, a Presence Subscription Request will automatically be reverted to your buddy for approval.
Please see Managing Presence Subscriptions for more information,
StreetViews & Map { Content }
Every location on earth has a global address, given as two numbers called coordinates. The two numbers ("Lat/Long") are a location's latitude number (north-south) and its longitude number (east-west). Together with help from google global location service, you can display the gloabl address in graphical views as streetViews and map of the location understand by human.
aTalk has implemented GPS location tracking, displaying both the streetViews and map on user device screen. The tool allows either a single location fix update or in continuous locations fix update mode. The continous mode update is triggered by two parameters changes i.e. distance delta or elapsed time. Either condition will trigger a new location fix fetch. The user selectable distance range varies from 0~500m with 5m steps; while the elapse time can range from 5~1000S in 10S interval. In continuous mode, user may choose only to send the location messages without displaying the realtime updates of streetViews and map information. This is done by not selecting the Continuous StreetViews & Map update option to conserve data usage.
On the streetViews and map display screen, you can select (press and hold) the little orange man figure and then drag to a new location on the display map, the streetView display will also be updated according to the new selected map location. You can also change the device pointing direction for a 360° panoramic view of the current select location on the map. Following suggests other possible use of this tool.
Send GPS-Location message: The tool allows user to delay his/her current GPS location in a single or continuous mode to his/her buddy as GeoLocation chat messages, i.e. only the longtitue and latitute information are being sent. This feature is enabled from within the chat window menu Send GPS-Location option. When your buddy selects the SteetView & Map button on the received location message, your current location is displayed on his/her device screen. The steetViews and map display on your buddy device automatically gets updated when your new locations are streamed via continuous mode; tracking your move in realtime. Note: To protect your privacy, this feature cannot be accessed or enabled remotely.
Show GPS Location: You may use the tool as it without sending any of your current GPS location as message. This feature is accessed from the contact list main menu StreetViews & Map. Hint: You may use this feature to make sure you are heading in the direction toward your nearby destination.
Locations playback animation: If you have the location history messages in the chat window, long press SteetView & Map button on any of location messages starts the location playback animation at interval of 2S. The playback anmiation either applies to incoming or outgoing messages grouping pending on which message you have initiated the playback animation mode.
GPS Location Demo: The feature has a built-in demo. Long press the Cont. Location update (xm) @xSec button starts the GeoLocation in demo mode. The streetViews and map will continuous get updated at 2S interval assuming user is moving in the north-west direction. If you enable this demo while in chat mode with another device as your buddy, you can see that the buddy device tracks and synchronizes the streetViews and map display following the user device.
XEP-0045: Multi-User Chat { Content }
With multi-user chat (MUC) or group chat, in which XMPP XEP-0045 chat rooms are designated; several users can share chat messages at the same time. aTalk implements most of the common features for MUC messaging. Followings are few of the terminology pertaining to MUC operations.
In the main menu, sliding right will show a list of the chatRoom's in which you have once being actively participated in the MUC chat. These are likely to be persistent rooms. aTalk has the following MUC features implemented.
Join Chat Room: Select this option from the main menu to create new or re-join an existing room. Pending on your room privilege, you may supply the NickName and ChatRoom subject when joining the MUC.
Invite: While in MUC session, you may select this option to invite new participants to join the MUC room. An invitation message will be sent to all the invitees you have selected. Your contacts may accept, reject or ignore the invitation. Except for ignore option selected, the accept or reject reply from your buddy is displayed in the chat window.
Discussion History: Depending on local service policy or room configuration, a room may send discussion history to the newly join occupant. Whether such history is sent, and how many messages comprise the history, are determined by the chat service implementation or specific deployment depending on local service policy or room configuration. Talk can receive and display all the history messages, while removing any duplicated messages.
Chat room occupants: Anytime during MUC session, you may select this opton to query a list of the Room Occupants currently have active participation in the MUC room. The list is displayed in the chat window.
Converting a One-to-One Chat Into a Multi-User Conference: Sometimes it is desirable to convert a one-to-one chat into a multi-user conference. In a one-to-one chat, just select Invite option to add existing buddy and other new buddies to the chat. A new MUC room will be created including all the new participants selected.
If you attempt to open a member-only room when you are not in the room member list, the process will failed with an error message. You will no be able to receive or send any messages in the chat room. Likewise you will receive an error message if you attempt to destroy chatRoom when you are not the room owever.
[20180915] Stickers, Bitmoji and Emoji rich content sharing { Content }
aTalk v1.5.2 has added support for Stickers, Bitmoji and Emoji rich content sharing using Google Gboard keybard. The Google Gboard keyboad is normally pre-installed on the latest android devices. If your android device does not have the Gboard, you may install it from Google play store.
Android device with Google Gboard keyboard, it allows user to share sticker and Bitmoji in addition to the current emoji, in messaging apps like aTalk.
With Gboard, users can download third-party sticker packs and/or the Bitmoji app from the Google Play store; and then send these stickers and Bitmoji while using the Gboard keyboard. When using the Gboard keyboard, users first tap the emoji button, and then tap either the sticker button or the Bitmoji button to search for the content they would like to share with the buddy.
Plese refer to the following sites for more information:
[20180710] XEP-0198:Stream Management and ReConnection Manager { Content }
In wireless communications, fading is variation of signal with time, geographical position, and radio frequency. Fading is frequent in mobile devices and may cause momentarily newtork data lost or disconnection. To improve network communication reliablity and minimize data lost, aTalk implements both XEP-0198: Stream Management and Reconnection Manager.
In Stream Management, all stanza data exchanges between client and server are verified and acknowledged. When a stanza data is lost during fading, either entities will attempt to resend stanza data that has not been acknowledged by the recipient.
In event that a sudden lost of network connection is detected, Reconnection Manager will automatically start the reconnection sequence using the algorithm defined below:
aTalk requires network connection in standby mode in order to receive messages or media calls. If you disable all network connection during device standy, reconnection manager will kick in once it detects network lost, and continues until you manually exit aTalk. Do ensure either GSM network or WiFi network remains accessible when device goes into standby mode. If all network is disabled in standy mode, you may also need to restart aTalk when device is waked up.
Some of the availabe power saving mode that may affect aTalk operation during standby, options may vary depending on android device and OS version:
[20180710] Network Keep Alive - Ping Interval { Content }
Most of the newtwork service provider inherently terminates mobile devices TCP connection when it detects there is no data exchange activity for some elapse of time. The established internet TCP connection channel with the server may also be removed by the network after some idle time. If you find that your device is unable to receive messages in realtime or/and with aTalk goes offline frequently; you will need to go to [Account Settings... | Connection Settings] to select the Enable Keep Alive option and set the Ping Interval that is lower than the newtork data inactivity timer for your service provide and internet. A good starting value is 240-second for the ping interval; and tweak the value if necessary with 20-second steps for the optimal device performance.
When an established TCP data channel is terminated by network, neither android nor aTalk is able to detect this condition, until it failed while attempting to send data. Therefore Reconnection Manager is not triggered when the TCP data channel is removed. It is therefore necessary to send the keep alive ping at regular interval to detect this condition for Reconnection Manager to work.
Android Runtime Permissions Request { Content }
With Android 6.0 Marshmallow (API 23), a new runtime permission model has been introduced; Users are not prompted for permissions at the time of installing the app, rather app needs to check for and request permissions at runtime. Users can then allow or deny the permissions for the app, users can also grant or revoke permission anytime from the app settings.
Whenever user launches aTalk on Android M or higher, it prompts the user to grant if there is any missing required permission. For aTalk maximum performance and full features support, aTalk requires the user to grant permissions for the following services.
If any of the permissions is denied, aTalk may not work properly or may have unexpected behavior. If you have selected Don't ask again option, you will not be prompt on next aTalk launch; You need to go to android Settings -> APP INFO for aTalk to enable the permissions.

OMEMO Messaging
Why am I being asked to authenticate the contact during secured chat? { Content }
In order for a cryptographic system to make sense, decisions must be made whether a secure chat session is trustworthy. Authenticating a buddy helps to ensure that the person you are talking to is who he or she claims to be. This is done by verify the person fingerprint(s) that are presented to you; contact your buddy via an external channel, such as reading it out on the phone, scanning QR codes etc. If everything matches up, you then indicate in the dialog to trust or untrust the fingerprint(s). This process needs only be done once. However if you later decided to distrust a contact, you can change the trust state of the contact in menu "Settings... | Messaging Security | Crypto buddy fingerprints". During an omemo conference session, OMEMO messages will not be sent to all your defined untrusted buddies
Why the OMEMO option is grayed out in my chat session menu? { Content }
In order to support omemo session, both your buddy client application and the registered servers must support omemo services.
  • Your registered server and the servers of your chat partners must support PEP (XEP-0163) to store and exchange key bundles. Optionally your server should support Message Carbons (XEP-0280) and Message Archive Management (XEP-0313) to achieve message synchronization across all (on- and off-line) devices.
  • Your buddy installed client must support omemo service
What is Blind Trust Before Verification? { Content }
aTalk implements Blind Trust Before Verification with an option to enable or disable it. With the option:
  • enabled: first installed new devices of contacts that have not been verified before will be auto-trusted. However you will be prompted for manual confirmation when a verified contact adds new devices.
  • disabled: you will be prompted for manual confirmation on all devices installed by your contacts.
When do I have to perform "Regenerate Omemo identity"? { Content }
Every android device installed with aTalk will be assigned an omemo identification which is required for omemo messaging support. The identification of the omemoDevice is associated with an identityKeyPairs and is unique for each omemoDevice in the network. The identityKeyPairs contains both the Private and Public Keys. The public key is published and stored on the server. The private key is required during omemo message encryption and sending. You contact will retrieve the public key from the server and use it to decrypt the received omemo message.
In an unlikely event that the omemoDevice identityKeyPairs is corrupted, omemo messaging with your buddies is no logger possible. aTalk alerts you when it detected a corrupted identityKeyPairs. If the problem persists on relaunch aTalk, you then need to regenerate a new omemo identity to rectify the problem. From the main menu select "Settings... | Messaging Security | Regenerate OMEMO identities", select the account that is having problem. Then click "Regenerate Selected" button to proceed. Upon regenerated your OMEMO identity, all your contacts receive the new updated key fingerprint and are required to reverify your omemo identity.
Note: You need to relaunch aTalk after you have performed "Regenerate Omemo identity"

OTR Messaging
What are the OTR version supported by aTalk? { Content }
aTalk OTR implementation support all current versions of OTR i.e. V1, V2 and V3. During OTR setup, aTalk will attempt to use the highest possible OTR version that your buddy installed client can support.
Why the OTR option is grayed out in my chat session menu? { Content }
aTalk has few OTR options to control how OTR session should be handled. These option are user selectable in the main menu "Settings... | Messaging Security" [OTR MESSAGING SECURITY] section.
  • Private messaging: A prerequisite option that you much enable to allow OTR messaging. Otherwise OTR option is grayed out in the chat session menu.
  • Auto initiate private messaging: When enable, the OTR chat session will automatically be initiated when you start a chat session.
  • Require private messaging: The OTR chat session is enforced if your buddy also support OTR messaging.
  • Unlike Omemo, OTR session cannot be setup when your buddy is off-line.
Note: Omemo session has priority over OTR. If your buddy attempts to change to OTR session while a OMEMO session is in progress, aTalk will stop it and a message is displayed to that effect.

Media Call Communications
[20180613] Why the call options button are not shown on some of my contacts in the contact list? { Content }
aTalk supports both voice and video call sessions. To allow setting up any of these media call with your buddy, your buddy installed xmpp client must also support the respective media call service. During aTalk initial start up, all buddies will send its features supported via cap version hash embedded within its <presence/> stanza. aTalk then perform check on each buddy supported features via service discovery (XEP-0030) protocol; and enable only the respective media call options that are supported by your buddy client.
Note: The contact must support XEP-0115: Entity Capabilities, version 1.5.1.
[20180918] Media Call and Chat Message in-progress simultaneously { Content }
aTalk allows user to send chat messages while an active call is in progress. User may start a media call while in chat mode or vice-versa. Switching between the two modes is easily performed with the two special buttons i.e. Back-To-Chat while in call mode, and Back-To-Call while in chat mode. The Back-To-Call will only be shown when there is an active call in progess. Otherwise a voice message (mic) send button is shown instead.
When user switches to chat mode, all video streaming will be paused as there is no focus window for video display. However audio streaming remains active at all time. When user switches back to video call, the video streaming will start automatically. At this momemt, resume from paused video does face some problem at time.
When in chat mode, user may peform some simple tasks with the active call using the call notification panel as shwon below, without actually switching back to call mode.
[20180614] Jabber VoIP-PBX gateway Telephony (experimental) { Content }
One distinguishing characteristic of Jabber technologies has been the existence of gateways (also called "transports") between the Jabber network and legacy services. The legacy services can be other IM protocols like SIP, AIM, ICQ or even a PBX gateway allowing a jabber entity to make voice/video call to phones via landline or GSM network.
aTalk provides the necessary interface to allow user to make jabber voice/video call to PBX gateway installed on the user registered service. The gateway however must support the following XEP protocols
aTalk Telepohny option uses the following two paramteres, and are requires to be setup. These parameters can be found in [Account settings... | Telephony} section
VoIP communications security via SRTP with ZRTP, DTLS and SDES protocol. { Content }
The Voice over IP (VoIP) and other media applications uses Real-time Transfer Protocol (RTP). Many VoIP applications send RTP data over the public Internet in clear, thus the data is not protected from eavesdropping or modification. Therefore most VoIP applications are considered insecure today. aTalk supports SRTP and ZRTP etc to enhance the security for VoIP communications.
To enable SRTP call ecryption in aTalk. From main meneu select Account settings... and user account properties to edit, follow by Call Encryption setting. Check Enable call encryption option and select the desired Encryption protocols and arrange them in the preference order. Check the ZRTP signalling advertise over signalling if ZRTP protocol is selected.
[20180613] STUN, TURN, ICE & Jingle for NAT Traversal in media call setup
NATs (Network Address Translation) and firewalls play a very important role in securing and enhancing the usability of internal networks, however impose significant challenges in setting up a reliable VoIP call bewteen two end-points. STUN, TURN, and ICE are a set of IETF standard protocols for negotiating traversing NATs when establishing peer-to-peer communication sessions.
A host uses Session Traversal Utilities for NAT (STUN) to discover its public IP address and type of firwall when it is located behind a NAT/Firewall. It then uses this information to assist in establishing peer-to-peer VoIP connectivity.
While STUN is effective in addressing the NAT issue with most consumer NAT devices (routers), it doesn’t work effectively for many corporate networks. If the NAT/Firewall would not allow the two hosts to connect directly, they make a connection to a server implementing Traversal Using Relay around NAT (TURN), which will relay media between the two end-points.
Interactive Connectivity Establishment (ICE) is a framework that describes how to coordinate STUN and TURN to make a connection between two end-points.
Jingle specification defines an XMPP protocol extension for initiating and managing peer-to-peer (P2P) media sessions between two XMPP entities in a way that is interoperable with existing Internet standards.
Universal Plug and Play (UPnP) is a set of networking protocols that permits networked devices, such as personal computers, printers, Internet gateways, WiFi access points and mobile devices to seamlessly discover each other's presence on the network and establish functional network services for data sharing, communications, and entertainment. UPnP is intended primarily for residential networks without enterprise-class devices.
aTalk uses all these options when setting up call between two end-points. These user defined options can be found in Account settings... | ICE.

User Avatar
Why some of the avatars for my contacts in main menu are blank or with incorrect pictures? { Content }
aTalk implementation supports both XEP's defined specifications in handling the contact avatars i.e: Your contact installed client must use either of these methods to update and publish his avatar on the server. aTalk can then retrieve your buddies' avatars from the server for display. Otherwise aTalk will display the default avatar i.e. blank figure picture for contacts without one.
Each avatar images stored on server can be few KBytes in size. During the process of avatars retrieving from server, sometimes network communications may get interrupted or aTalk encountered reply timeout from server. This can lead to incorrect avatars being associated with your buddies. If the problem persist after you relaunch aTalk, please following the steps below to refresh your buddies' avatars.
How do I update my user avatar? { Content }
aTalk has an integrated picture editor that supports zooming, scaling and cropping. This simple tool helps publishing of user avatar an easy task. Please click here to return to main page, and playback the demo video for "User avatar" to get help on how to publish user avatar.
In order to allow your buddy installed client that supports only either one of the avatar protocols, aTalk uses both methods to update the avatar on the server. This does take some times to store the avatar on the server. So be patient when you update your own user avatar.

General
Why aTalk is not working properly on my old android devices? { Content }
aTalk installation requires android device with API 5.0 and above for full features support. To have satisfactory performance for both video call and cryptography etc, aTalk also requires reasonable fast multi-core CPUs. A slow android device is likely to have problem in handling the vast amount of information from incoming & outgoing streaming media data and cryptography processing. With aTalk installed on slow device, you may find response to user action is sluggish, and at time the screen turns black for a while before returning. Please be patient to wait if you in love and cannot part with your old android device.
Android N introduces Android Runtime (ART) with Ahead-Of-Time (AOT) compilation and improved garbage collection (GC), replacing Dalvik that combines bytecode interpretation with trace-based Just-In-Time (JIT) compilation. Android devices with JIT implementation do experience problems during some timing critical tasks. It is observed that JIT compilation actually extends the time in processing task e.g. the time gets added to during stanza exchanges with server, hence throws response reply timeout excpetion at times. This usually happens on the initial launch after installation of aTalk. If you do experience this problem, relaunchs aTalk may resolve the issue.
The initial aTalk released in Google play store actually allow the app to be installed on API 4.0.3, with expected degradation in performance due to some missing libraries support on these devices. You are advised only to install and operate aTalk on a newer device if you cannot accept these performance degradation. Pending on user feedback, future release of aTalk may remove support on devices with android version lower than API 5.0.
[20180808] aTalk - android OS API compatibility { Content }
Android Marshmallow is android 6.0 or API 23. Starting with API 23, android has proceeded with Text Relocations (Enforced for API level >= 23). This means all shared objects in the installed apk must not contain any text relocation code i.e. the code must be loaded as is and must not be modified. Such an approach reduces load time and improves security. aTalk implementatation uses third party libraries, and one of its native libraries i.e. ffmpeg has text relocation when compiled for anroid with x86 cpu architecture. Android aborts loading of any library with text relocation. Library ffmpeg is ued by aTalk to support the media call services. Therefore when you install aTalk on an x86 android device with API-23 or higher, all the media services will be disabled and not available to the user. Beside this, all other aTalk features should be working. Please refer to the following site for more information:
https://android.googlesource.com/platform/bionic/+/master/android-changes-for-ndk-developers.md#text-relocations-enforced-for-api-level-23
Why do I see screen displaying "shutting down ..." message on re-launch after exit? { Content }
When you exit from aTalk, the application must inform your registered server so that the client state is properly synchronized and also to give time to server to perform some house keeping tasks. When the server has completed the necessary tasks, it sends an acknowledgement i.e. </stream> to inform the client, only then aTalk can proceed to close the connection and exit. If this required acknowledgement is not received due to network error etc, aTalk waits until a predefined reply time period has elapsed before exit. aTalk globally set the reply timeout to 10-seconds, this is to allow servers with high latency and for slow devices to operate properly.
How can I give feedback to the developer for any aTalk problem encountered? { Content }
aTalk has a built-in debug log utility that capture any runtime exceptions. In the event if you experienced problem with aTalk, you can forward this log information to the developer to identity the cause of the problem and to provide solutions in the next release if possible. To send the debug log, from main menu select "Help | Report Bugs", then pick your email client to send. To help developer to quickly identity the problem. a brief description of how the problem happen certainly help. Send the mail after you are done.
The log contains only the required information necessary to help identify the problem. No personnel sensitive inform are being included. The log will be deleted once the problem is identified and no copies of the log are being kept.