Chat-like message types and interface #1616

New Issue

2020-04-29T03:01:27+02:00

PeterSurda commented

2020-04-29 03:01:27 +02:00

(Migrated from github.com)

During development of the android interface I realised that a chat-like interface may be more user friendly than an email-like interface. I propose a protocol change for chat-like objects. They would use a new message type, and a bit in the pubkey bitfield would indicate whether the address should be used for chat message types instead of email-like message type.

The chat message type would contain a reference to previous objects (so that ordering can be done by the client), and could contain UTF-8 text, images or audio (maybe with separate message types for each, or all in one). Video wouldn't fit within maximum object size, so can probably be skipped. For audio, I tested the Opus codec, which produces about 7kbit/s file at the minimum size and still is understandable. Opus codec is widely supported by open source implementation and a python package.

For compatibility outside of kivy, the QT interface would contain another tab for a chat interface. The API would have to be updated too.

For storing, a new table is proposed.

I also propose to extend the messagetype class to allow not only encoding / decoding, but also saving/loading/searching/etc. For old message types it can be refactored later.

This proposal can be implemented independently of my recent proposal for getting rid of pubkey objects #1612 .

During development of the android interface I realised that a chat-like interface may be more user friendly than an email-like interface. I propose a protocol change for chat-like objects. They would use a new message type, and a bit in the pubkey bitfield would indicate whether the address should be used for chat message types instead of email-like message type. The chat message type would contain a reference to previous objects (so that ordering can be done by the client), and could contain UTF-8 text, images or audio (maybe with separate message types for each, or all in one). Video wouldn't fit within maximum object size, so can probably be skipped. For audio, I tested the [Opus](https://en.wikipedia.org/wiki/Opus_(audio_format)) codec, which produces about 7kbit/s file at the minimum size and still is understandable. Opus codec is widely supported by open source implementation and a [python package](https://pypi.org/project/opuslib/). For compatibility outside of kivy, the QT interface would contain another tab for a chat interface. The API would have to be updated too. For storing, a new table is proposed. I also propose to extend the messagetype class to allow not only encoding / decoding, but also saving/loading/searching/etc. For old message types it can be refactored later. This proposal can be implemented independently of my recent proposal for getting rid of pubkey objects #1612 .

This repo is archived. You cannot comment on issues.