Areas of activity

[Zaki Manian]

Thanks so much for go textsecure Janimo. The presence of a nice toy interface for Axolotl has massively improved my traction on helping out on Whisper Systems stuff. 

I'm principally working on the following as time permits.

• Adding support for the websocket changes that in the staging server so we can interoperate with TS browser.
  
• A simple session management interface
• Groups support.

[Jani Monoses]

Hello Zaki,

I just noticed you started to work on the session stuff (client app only AFAICT). I think the included command line app should be a minimum and somewhat usable test of the lib API, whereas a more user friendly app should be a standalone app/repo with its own development pace. Either something with a simple UI as the current one but more robust and featureful, or a ncurses based one :)

For websocket interop on the staging server I did some initial work until I saw I can use the official servers with websocket.

Line 154 in websocket.go uncomments I line that seemed sufficient to replace the base64 encoding one above it in order to properly receive messages on websocket from the staging server.

I did not know what exactly the websocket changes planned wee besides this, so I had decided to punt the issue until there's server code or docs published.

Groups support I have started looking into as well.

cheers

Jani

--
You received this message because you are subscribed to the Google Groups "textsecure-go" group.
To unsubscribe from this group and stop receiving emails from it, send an email to textsecure-g...@googlegroups.com.
To post to this group, send email to textse...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/textsecure-go/aed78f5a-b3ba-4fae-a96f-e0091856cbc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tyler Manson]

Howdy list members,

If developing a command-line or GUI based client via this library is
something we're interested in and you say: "a more user friendly app
should be a standalone app/repo" has anybody yet made said repo, and if
not should we make said repo?

My understanding based on the current structure of the code is that the
cmd directory is supposed to hold the code to "test" the library, which
right now, is the "client," and then the rest of the code is in the base
directory. Are you intending at some point to take that functionality
out of the cmd folder and into its own repo?

Also I don't see where incoming messages are actually printed to the
screen. Around line 310 in textsecure.go I see the message being
decrypted into plaintext in the handleReceivedMessage function, but I
don't see that plaintext ever printed to the screen.

If we want to expand functionality of the client to be able to handle
more than one conversation at one time, then we need to be able to
differentiate and store messages from different people in different
places. Is that what store.go, and the .storage/sessions directory is
about? I wasn't quite sure about that either.

I am potentially interested in taking this work and making a QT client
out of it, for Maemo/Linux/Windows/Mac.


Tyler

[Jani Monoses]

Hello,

If developing a command-line or GUI based client via this library is
something we're interested in and you say: "a more user friendly app
should be a standalone app/repo" has anybody yet made said repo, and if
not should we make said repo?

I find value in a simple client app being in the same repo, to ease installation, development and testing. Even a QML one would make sense there (on my TODO list) as long as it is barebones and mostly for testing the interfacing with the package and to serve as a proof of concept.

OTOH a full-fledged ncurses, gkt or qml would probably make more sense as a separate repo so we do not get unrelated commit histories for the package and the app.

My understanding based on the current structure of the code is that the
cmd directory is supposed to hold the code to "test" the library, which
right now, is the "client," and then the rest of the code is in the base
directory. Are you intending at some point to take that functionality
out of the cmd folder and into its own repo?

I'd keep that app there, for the reasons stated above. Of course more regular  tests are needed in the tree, but this simple user app is useful.

 

Also I don't see where incoming messages are actually printed to the
screen. Around line 310 in textsecure.go I see the message being
decrypted into plaintext in the handleReceivedMessage function, but I
don't see that plaintext ever printed to the screen.

Maybe you looked at the message handler for echo mode, where it just sends back the message? Try a git pull, the code has been reworked in the past 2 days. 

If we want to expand functionality of the client to be able to handle
more than one conversation at one time, then we need to be able to
differentiate and store messages from different people in different
places. Is that what store.go, and the .storage/sessions directory is
about? I wasn't quite sure about that either.

Handing more than one conversation is a UI issue, the store.go and .storatge/session dirs are related to separate sessions being managed already by the lib.

A very simple and not user friendly way of handling multiple conversation by only touching the cmd/ app is by printing the incoming messages prefixed by the source number,

and when sending typing the messages as contact:messagebody. Not convenient, but enough for testing. That is why I think a curses based or similar text UI is more appropriate for those who would want to use this from the console.

I am potentially interested in taking this work and making a QT client
out of it, for Maemo/Linux/Windows/Mac.

Me too, my goal besides the ones you mention is the Ubuntu phone, so a QML interface integrated with the APIs provided by that platform.

I just kept postponing that aspect, in order to get the basics in shape.

Jani