No reviewers
Labels
No labels
Android
CS::needs customer feedback
CS::needs follow up
CS::needs on prem installation
CS::waiting
Chrome
Design:: Ready
Design:: in progress
Design::UX
E2EE
Edge
Firefox
GDPR
Iteration 13 IM
Linux
MacOS
Need::Discussion
Need::Steps to reproduce
Need::Upstream fix
Needs:: Planning
Needs::Dev-Team
Needs::More information
Needs::Priority
Needs::Product
Needs::Refinement
Needs::Severity
Priority::1-Critical
Priority::2-Max
Priority::3-Impending
Priority::4-High
Priority::5-Medium
Priority::6-Low
Priority::7-None
Progress::Backlog
Progress::Review
Progress::Started
Progress::Testing
Progress::Triage
Progress::Waiting
Reporter::Sentry
Safari
Target::Community
Target::Customer
Target::Internal
Target::PoC
Target::Security
Team:Customer-Success
Team:Design
Team:Infrastructure
Team:Instant-Messaging
Team:Product
Team:Workflows
Type::Bug
Type::Design
Type::Documentation
Type::Feature
Type::Improvement
Type::Support
Type::Tests
Windows
blocked
blocked-by-spec
cla-signed
conduit
contribution::advanced
contribution::easy
contribution::help needed
from::review
iOS
p::ti-tenant
performance
product::triage
proposal
refactor
release-blocker
s: dart_openapi_codegen
s::Famedly-Patient
s::Org-Directory
s::Passport-Generator
s::Requeuest
s:CRM
s:Famedly-App
s:Famedly-Web
s:Fhiroxide
s:Fhiroxide-cli
s:Fhiroxide-client
s:Fhirs
s:Hedwig
s:LISA
s:Matrix-Dart-SDK
s:Role-Manager
s:Synapse
s:User-Directory
s:WFS-Matrix
s:Workflow Engine
s:dtls
s:famedly-error
s:fcm-shared-isolate
s:matrix-api-lite
s:multiple-tab-detector
s:native-imaging
severity::1
severity::2
severity::3
severity::4
technical-debt
voip
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Matthias/conduit#843
Loading…
Reference in a new issue
No description provided.
Delete branch "presence"
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?
This MR adds the capability to handle presence-over-federation EDUs, which allows users to see status of users from other servers.
Linked issues
TODO
assigned to @M0dEx
marked the checklist item (Unreliably) Send presence updates over federation as incomplete
marked the checklist item Database cleanup as incomplete
marked the checklist item Keeping presence up-to-date (timed tasks?) as incomplete
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
marked the checklist item Keeping presence up-to-date (timed tasks?) as completed
changed the description
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
marked the checklist item (Unreliably) Send presence updates over federation as completed
added 1 commit
Compare with previous version
added 2 commits
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
marked the checklist item Database cleanup as completed
I'd welcome reviews and some tips on how to make this a bit cleaner.
requested review from @timokoesters
marked this merge request as ready
Those two
filter_map
can be joinedJust minor suggestions
changed this line in version 14 of the diff
added 1 commit
Compare with previous version
resolved all threads
Thanks for those!
added 30 commits
next
cd5a83d4
- feat(presence): start presence timeout implementationdeeffde6
- feat(presence): restructure database trees for presencef956e727
- feat(presence): refactor presence_sincee7348621
- feat(presence): implement most features for PoCb6541d20
- fix(presence): fix default timeout valuesb18b228c
- fix(presence): fix issues found when testing42b27f2f
- style(presence): reformat with cargo8efcec62
- feat(presence): send presence events for own users unreliably5bdc0312
- style(presence): reformat with cargo fmt5e4e4d00
- style(config): remove useless castf9d10e8f
- feat(presence): start work on cleanup task8d161c6a
- feat(presence): finish presence cleanup task230f09f8
- style(presence): reformat63ac118d
- fix(presence): move sleep in presence cleanup77b555f2
- fix(presence): don't cause panicdd85316b
- fix(presence): allow services to start before running tasks4d22cb50
- feat(presence): remove old presence updates2eb5907d
- fix(presence): fix configuration values for presence status50252678
- style(presence): code cleanupCompare with previous version
added 2 commits
f269a15c
- chore: code cleanup / cargo clippya6d5bfe3
- Merge branch 'Nyaaori/cleanup-presence' into 'presence'Compare with previous version
Is there a way to disable/enable this in the config if the user so chooses to? I'm not seeing a way in this MR.
added 1 commit
1f698718
- feat(presence): add configuration option to disable presenceCompare with previous version
added 1 commit
70652fe0
- style(presence): reformat with cargo fmtCompare with previous version
Added in the latest commits.
resolved all threads
added 1 commit
b4356917
- style(presence): make type alias for presence_since iterCompare with previous version
added 1 commit
46676267
- config(example): add allow_presenceCompare with previous version
added 1 commit
8257d044
- fix(presence): check for allow_presence only after services are availableCompare with previous version
I think this comment is outdated?
It looks to me like update_count and update_timestamp always have the same value, would it make sense to combine them into one parameter called
active
(meaning the user actively initiated this change)?Can you give a short explanation on what this code does? What does it mean to compare the curr and prev presence state?
No it is not - the reason I put it there is that we still do not have any component to reliably send events like these over federation.
What I am trying to do there is to update the DB count through ping_presence only if the presence state changes. If the presence states are equal, nothing has changed and we do not need to needlessly update the count.
Unfortunately, they do not always have the same value. For example, in
presence_maintain
,update_count
istrue
whileupdate_timestamp
isfalse
.Sorry for the delay, the reason why I haven't merged it yet is because the code uses timestamps to calculate the presence state and that will make it difficult to add manual presence changes (see /sync set_presence). It's probably possible to hack it into this code, but there is probably a cleaner solution, what do you think?
Ah, I see.
What if the code only changed the state in presence_maintain if the state degraded (eg. online -> idle and idle -> offline)?
That seems like a more elegant solution that would respect set_presence /sync.
It will, however, require a bit of a redesign.
That sounds better, yes. Saving the current presence state and the timestamp of the last (manual?) presence change should work, right? (Only one timestamp should be enough)
I will have to rethink the entire presence code, probably.
marked this merge request as draft
Pull request closed