add a device-chat #794

r10s · 2019-11-03T23:36:53Z

we want to have a system-"chat" for various purposes:

showing update information there
adding hints eg. about how to optimize battery, multi-device hints etc. - things that we find out during runtime
messages are generated totally offline, by the app itself, we have to make that clear in a message we add to the channel then.
the idea is that users in a chat tool are very aware of chatting - a message in an alert or even a sticky thing is easily clicked away. with a chat, the user can also come back later to an issue.

from the ui point of view, the system-chat is a normal chat, not many special things are needed. this pr currently only prototypes the ffi, however, the implementation of these functions should be pretty simple.
and, nothing prevents us to add a simple image here and there :)

once done, we can have more top level-things on that, eg. a method to add things only once to the channel or a update-info and so on.

~~wrt naming: any suggestions are welcome - otherwise, i fear we stick to the name "clippy" :)~~

nb: beside DC_CONTACT_ID_CLIPPY, there is aready another "system" user, DC_CONTACT_ID_DEVICE that is the user-id of the centered messages as "member added", "setup changes" etc. as these messages may also appear inside the clippy-chat, we need an extra contact-id.

hpk42 · 2019-11-04T01:24:03Z

I really like "DC_CONTACT_ID_DEVICE" and thus would suggest to talk about "device chat" -- it's much better than clippy which invokes an annoying remote data-tracking AI-agent ... or conversely the "cargo clippy" thingie. This is user-visible how we talk about it in FAQs etc. Device chat emphasizes that it's just your local system informing you of something (also tips like "turn on background service" etc.) or suggesting to do a backup after you have 100 chat messages or 10 chats or so. The AI part can then come later but would run fully local at least ;)

hpk42

this looks fine though i hope you do a global replace clippy->device ;)

r10s · 2019-11-04T11:04:13Z

the problem is that DC_CONTACT_ID_DEVICE is already in use for the "member added" etc. but it seems no to be used by the ui (they use dc_msg_is_info()), we can maybe rename it to DC_CONTACT_ID_INFO or so.

r10s · 2019-11-04T11:48:50Z

okay, the things are named DC_CONTACT_ID_DEVICE (5) and dc_chat_is_device_talk() now.

the old DC_CONTACT_ID_DEVICE (2) is now DC_CONTACT_ID_INFO (2) - this is only an internal rename, at least our uis use dc_msg_is_info() and also DC_CONTACT_ID_DEVICE was never documented somewhere before.

flub

I am surprised the device chat is a Param on the Chat rather than a special chat id. Why this way?

flub · 2019-11-04T20:37:40Z

deltachat-ffi/src/lib.rs

@@ -811,6 +811,23 @@ pub unsafe extern "C" fn dc_set_draft(
        .unwrap_or(())
 }

+#[no_mangle]
+pub unsafe extern "C" fn dc_add_device_msg(context: *mut dc_context_t, msg: *mut dc_msg_t) -> u32 {


Not a libc::?? return type?

well, i did just a copy+paste from dc_chat_can_send() :)

i leave it for now, maybe we can go trough the ffi and streamline this at some point for all affected functions.

libc::uint32_t is deprecated in favor of u32 in Rust. And using u32 is better than libc::c_uint because JNI and NAPI don't work these C types anyway.

Keep it returning u32 and specify it as uint32_t in C API.

If we are going to streamline it, I would rather change all ints to int32_t, because it is equal to int32_t on all existing architectures anyway.

thanks for explaining, @link2xt

flub · 2019-11-04T20:40:02Z

deltachat-ffi/deltachat.h

+ * @param chat The chat object.
+ * @return 1=chat is writable, 0=chat is not writable
+ */
+int             dc_chat_is_writable           (const dc_chat_t* chat);


maybe this is a weird name, to me a non-writable chat would be one which can not have any messages in it ever.
maybe dc_chat_can_send or something?

yip, this sounds better. i will change it.

flub · 2019-11-04T20:45:45Z

src/chat.rs

@@ -677,8 +691,7 @@ pub fn msgtype_has_file(msgtype: Viewtype) -> bool {
    }
 }

-fn prepare_msg_common(context: &Context, chat_id: u32, msg: &mut Message) -> Result<MsgId, Error> {
-    msg.id = MsgId::new_unset();
+fn prepare_msg_blob(context: &Context, msg: &mut Message) -> Result<(), Error> {


this is a nice refactor

flub · 2019-11-04T20:51:53Z

src/chat.rs

+    prepare_msg_blob(context, msg)?;
+    unarchive(context, chat_id)?;
+
+    context.sql.execute(


why is this a custom insert? I appreciate you don't want to call send_msg() but i'm surprised to see a whole new sql query. I probably missed something though.

there is just no other INSERT INTO msgs that would only do an insert. the ones in receive_imf(), set_draft(), set_info_msg() do other, unwanted stuff and/or have a customized insert on their own.

but i think this is no issue. these sqls are easy enough and so it is pretty clear what happens.

r10s · 2019-11-04T22:01:43Z

I am surprised the device chat is a Param on the Chat rather than a special chat id. Why this way?

i was also thinking about using a DC_CHAT_ID_DEVICE ...

i think it is easier this way as there are many cases checking for DC_CHAT_ID_LAST_SPECIAL - so many things would not work with a DC_CHAT_ID_DEVICE out of the box and need adaptions.
this would also affect many sql-statements
the device-chat is a pretty normal chat from the view of the ui
if think the device-chat is similar to the me-chat (aka saved-messages) - so it is nice to have a similar behavior here
we save one special-chat-id :)

so, these special-ids are more for chats that should not appear in mosts list and are no real chats in reality - eg. the virtual deaddrop, the archive-link etc.

all in all, it's easier for the device-chat to be a "normal" chat.
(in contrast to the device-contact: here we use DC_CONTACT_ID_DEVICE as it shall not appear as a "normal" contact in lists, shall not be blockable or deletable etc.)

link2xt · 2019-11-05T00:40:22Z

Is there any place to read initial discussion on this feature? Was it on IRC? Completely missed that.

r10s · 2019-11-05T09:46:06Z

Is there any place to read initial discussion on this feature? Was it on IRC? Completely missed that.

it was mostly offline and on irc iirc :)

r10s · 2019-11-05T10:23:59Z

nb: the current device-chat-logo is ugly, i have an idea and will replace it. @hpk42 so maybe wait with merging.

…dc_msg_is_info()

…ould already be avoided in the ui)

r10s · 2019-11-06T01:23:48Z

this is what it looks like now:

hpk42 · 2019-11-06T12:33:43Z

great work, looking forward to seeing it in action ;)

hpk42 approved these changes Nov 4, 2019

View reviewed changes

r10s changed the title ~~prototype a system-chat~~ [wip] prototype a system-chat Nov 4, 2019

r10s force-pushed the clippy2 branch from c585577 to 8c68528 Compare November 4, 2019 11:44

r10s force-pushed the clippy2 branch 7 times, most recently from 0d791d0 to 4f18be9 Compare November 4, 2019 19:36

r10s changed the title ~~[wip] prototype a system-chat~~ add a device-chat Nov 4, 2019

flub reviewed Nov 4, 2019

View reviewed changes

r10s added 8 commits November 5, 2019 22:57

rename DC_CONTACT_ID_DEVICE to DC_CONTACT_ID_INFO to be in-line with …

8017c12

…dc_msg_is_info()

prototype a device-chat

8b6b9ec

basic devicetalk implementation

5380a96

create separate function for preparing a blob

024f034

implement add_device_msg()

15031f1

add devicemsg to repl tool

ba1e79f

get contact- and chat-info for device-messages

8733d66

target comments of @flub

7791f77

r10s force-pushed the clippy2 branch 2 times, most recently from 59c06ed to e654874 Compare November 5, 2019 22:28

r10s mentioned this pull request Nov 5, 2019

adapt to device-messages api deltachat/deltachat-android#1107

Merged

r10s changed the title ~~add a device-chat~~ [wip] add a device-chat Nov 5, 2019

r10s added 4 commits November 6, 2019 02:20

add profile-icon for device-chat

c614550

show chat-profile-image in repl tool

01ae2bb

block sending to chats that do not support sending (normally, this sh…

13d12a7

…ould already be avoided in the ui)

correct ffi return value of dc_add_device_msg()

b59c421

r10s force-pushed the clippy2 branch from e654874 to b59c421 Compare November 6, 2019 01:20

r10s changed the title ~~[wip] add a device-chat~~ add a device-chat Nov 6, 2019

hpk42 merged commit 515f0c5 into master Nov 6, 2019

r10s deleted the clippy2 branch November 6, 2019 13:47

r10s mentioned this pull request Nov 7, 2019

disable bcc_self on new installations #733

Closed

Uh oh!

add a device-chat #794

add a device-chat #794

Uh oh!

Conversation

r10s commented Nov 3, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hpk42 commented Nov 4, 2019

Uh oh!

hpk42 left a comment

Choose a reason for hiding this comment

Uh oh!

r10s commented Nov 4, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

r10s commented Nov 4, 2019

Uh oh!

flub left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

link2xt Nov 5, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

r10s commented Nov 4, 2019

Uh oh!

link2xt commented Nov 5, 2019

Uh oh!

r10s commented Nov 5, 2019

Uh oh!

r10s commented Nov 5, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

r10s commented Nov 6, 2019

Uh oh!

hpk42 commented Nov 6, 2019

Uh oh!

Uh oh!

r10s commented Nov 3, 2019 •

edited

Loading

r10s commented Nov 4, 2019 •

edited

Loading

link2xt Nov 5, 2019 •

edited

Loading

r10s commented Nov 5, 2019 •

edited

Loading