genofire
/
unified-push-xmpp
2
1
Fork 1
Code Issues 6 Pull Requests 3 Projects Releases Activity

Catch up to past messages after reconnecting #8

New Issue
Open
opened 2021-09-14 05:11:19 +02:00 by karmanyaahm · 9 comments
karmanyaahm commented 2021-09-14 05:11:19 +02:00
Collaborator
Copy Link

If the device is offline for a while this should go back to look at what messages have been sent before. This will probably be solved after #2 because no persistent storage mechanism is defined yet.

If the device is offline for a while this should go back to look at what messages have been sent before. This will probably be solved after #2 because no persistent storage mechanism is defined yet.
genofire commented 2021-09-14 08:29:30 +02:00
Owner
Copy Link

Normaly the XMPP-Server should store offline messages till client reconnect.
I am not sure why it does not work, maybe problems are:

  • the distributer change is ressource after reconenct
  • the gateway use ressouce to deliever messages (for sending messages only to single distributor)
Normaly the XMPP-Server should store offline messages till client reconnect. I am not sure why it does not work, maybe problems are: - the distributer change is ressource after reconenct - the gateway use ressouce to deliever messages (for sending messages only to single distributor)
genofire added the
bug
 label 2021-09-14 08:29:41 +02:00
genofire commented 2021-09-14 08:48:36 +02:00
Owner
Copy Link

if distributer is offline (and gateway recieve an message) it will deliever message after restart of distribute on my instance.

Maybe application miss the message if the distributer send it to dbus without an reciever.

Looks good for me -> maybe we should run an startup test of distributor if xmpp-account-server has offline messages: https://xmpp.org/extensions/xep-0160.html

Maybe we should send:

if distributer is offline (and gateway recieve an message) it will deliever message after restart of distribute on my instance. Maybe application miss the message if the distributer send it to dbus without an reciever. Looks good for me -> maybe we should run an startup test of distributor if xmpp-account-server has offline messages: https://xmpp.org/extensions/xep-0160.html Maybe we should send: - delay https://xmpp.org/extensions/xep-0203.html
karmanyaahm commented 2021-09-15 05:24:18 +02:00
Author
Collaborator
Copy Link
the distributer change is ressource after reconenct
the gateway use ressouce to deliever messages (for sending messages only to single distributor)

I'm pretty sure that's not the problem because the following happens:

  1. Register an app - keep the app running
  2. Send a message - works, of course
  3. Turn off the distributor
  4. Send a message - this message is never received, (not even after step 5)
  5. Turn on the distributor
  6. Send a message - this works

This might be specific to xmpp extensions on my instance? I'll have to look into this further and see.

> the distributer change is ressource after reconenct the gateway use ressouce to deliever messages (for sending messages only to single distributor) I'm pretty sure that's not the problem because the following happens: 1. Register an app - keep the app running 2. Send a message - works, of course 3. Turn off the distributor 4. Send a message - this message is never received, (not even after step 5) 5. Turn on the distributor 6. Send a message - this works This might be specific to xmpp extensions on my instance? I'll have to look into this further and see.
👍 1
genofire commented 2021-09-15 12:55:46 +02:00
Owner
Copy Link

Thanks for your checklist, that is what works for me :(

I am also believe, that is a problem of an deactivated XEP for offline messages.

Therefore i like to write an check in the distributor, that print a warning, if this extentions is not available.

Thanks for your checklist, that is what works for me :( I am also believe, that is a problem of an deactivated XEP for offline messages. Therefore i like to write an check in the distributor, that print a warning, if this extentions is not available.
genofire added the
distributor
 label 2021-09-15 12:56:53 +02:00
karmanyaahm commented 2021-09-15 16:08:21 +02:00
Author
Collaborator
Copy Link

I'm pretty sure it works on my server because I can access messages in Conversations after clearing data.

This probably needs to be implemented in the distributor, I'll see if I can do it today: https://mellium.im/xmpp/history/

I'm pretty sure it works on my server because I can access messages in Conversations after clearing data. This probably needs to be implemented in the distributor, I'll see if I can do it today: https://mellium.im/xmpp/history/
genofire commented 2021-09-15 17:08:00 +02:00
Owner
Copy Link

do you use your account only for this distributor?

  • msgoffline would not be the solution then (i write a check for it)
  • i believe we have to fetch the history then (and maybe delete delivered message from them)
do you use your account only for this distributor? - `msgoffline` would not be the solution then (i write a check for it) - i believe we have to fetch the history then (and maybe delete delivered message from them)
genofire commented 2021-09-15 20:40:37 +02:00
Owner
Copy Link

so if the msgofflineis supported is now checked on startup - do you become this warning?

so if the `msgoffline`is supported is now checked on startup - do you become this warning?
karmanyaahm commented 2021-09-16 03:23:37 +02:00
Author
Collaborator
Copy Link

do you use your account only for this distributor?

no, i have conversations and dino as well. maybe that's the issue.

I don't get the 'your server does not support offline messages (XEP-0160)' message.

I tried turning off both dino and force stopping conversations, and then trying the whole process, but still doesn't work.

Maybe https://mellium.im/xmpp/history/ (xep-0313), which both dino and conversations use, would work better since it can conditionally request certain chats. I'll run some tests with it pretty soon and will let you know how it works.

> do you use your account only for this distributor? no, i have conversations and dino as well. maybe that's the issue. I don't get the 'your server does not support offline messages (XEP-0160)' message. I tried turning off both dino and force stopping conversations, and then trying the whole process, but still doesn't work. Maybe https://mellium.im/xmpp/history/ (xep-0313), which both dino and conversations use, would work better since it can conditionally request certain chats. I'll run some tests with it pretty soon and will let you know how it works.
genofire commented 2021-09-16 03:33:47 +02:00
Owner
Copy Link

BTW: in conversations you have the option to disable your account

Yes i believe that is the problem - there is also a problem when you have on modern client online - there have active carbon-copy ....

okay so i believe we really have to scrape the history

BTW: in conversations you have the option to disable your account Yes i believe that is the problem - there is also a problem when you have on modern client online - there have active carbon-copy .... okay so i believe we really have to scrape the history
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
license
docs-service-discovery
Labels
Clear labels   
bug

Something is not working

  
distributor

Distributor (DBus) component

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
gateway

Gateway component

  
help wanted

Need some help

  
invalid

Something is wrong

  
question

More information is needed

  
wontfix

This won't be fixed

No Label
bug
distributor
duplicate
enhancement
gateway
help wanted
invalid
question
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: genofire/unified-push-xmpp#8
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?