bonfire-xmpp / bonfire Goto Github PK

Calling getRoster() seems to only get JIDs. Populate it with avatars, moods and presences in a list in the store, so that we can display rich data in the UI.

Can you add the support of RFC 9266: Channel Bindings for TLS 1.3?

• https://datatracker.ietf.org/doc/html/rfc9266

Little details, to know easily:

• tls-unique for TLS =< 1.2
• tls-exporter for TLS = 1.3

Thanks in advance.

A central settings screen. Popups and dialogs feel like context actions, so a new route?

Add support for Markdown and TeX within messages.

Can you add supports of:

• SCRAM-SHA-1
• SCRAM-SHA-1-PLUS
• SCRAM-SHA-256
• SCRAM-SHA-256-PLUS
• SCRAM-SHA-512
• SCRAM-SHA-512-PLUS
• SCRAM-SHA3-512
• SCRAM-SHA3-512-PLUS

You can add too:

• SCRAM-SHA-224
• SCRAM-SHA-224-PLUS
• SCRAM-SHA-384
• SCRAM-SHA-384-PLUS

"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".

• SCRAM-SHA-1(-PLUS):
  -- https://tools.ietf.org/html/rfc5802
  -- https://tools.ietf.org/html/rfc6120

• SCRAM-SHA-256(-PLUS):
  -- https://tools.ietf.org/html/rfc7677 since 2015-11-02
  -- https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA

• SCRAM-SHA-512(-PLUS):
  -- https://tools.ietf.org/html/draft-melnikov-scram-sha-512

• SCRAM-SHA3-512(-PLUS):
  -- https://tools.ietf.org/html/draft-melnikov-scram-sha3-512

• SCRAM BIS: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms:
  -- https://tools.ietf.org/html/draft-melnikov-scram-bis

https://xmpp.org/extensions/inbox/hash-recommendations.html

-PLUS variants:

• RFC5056: On the Use of Channel Bindings to Secure Channels: https://tools.ietf.org/html/rfc5056
• RFC5929: Channel Bindings for TLS: https://tools.ietf.org/html/rfc5929
• Channel-Binding Types: https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml
• RFC 9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/html/rfc9266

IMAP:

• RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2: https://tools.ietf.org/html/rfc9051

LDAP:

• RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803

HTTP:

• RFC7804: Salted Challenge Response HTTP Authentication Mechanism: https://tools.ietf.org/html/rfc7804

2FA:

• Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication: https://datatracker.ietf.org/doc/html/draft-ietf-kitten-scram-2fa

IANA:

• Simple Authentication and Security Layer (SASL) Mechanisms: https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

Linked to:

• scram-sasl/info#1

Messages should be searchable, both by plain-text and select predicates (relevant chat, date(s), content type, etc.).

I think the flickering should only last as long as the query is active, then the 'waterfall' delay effect should play.

Originally posted by @00drip in #46 (comment)

Also, implement a few different animations, and then pick one randomly on refresh mayhaps?

Preferably use breakpoints so that it works in browsers too

XEP-0115 makes supporting clients (and servers) generate a unique hash for their disco caps. That way, we can save on bandwidth by caching per ID, as well as stopping 'disco floods' as same-version clients with the same hash share the same caps.

Also, look into our entity cap data

Set up CI/CD to enforce code style and perform lint checks/mock builds

IndexedDB blocks are written for an arbitrary number of messages, but they are not loaded at the proper time (i.e. when switching into a chat or scrolling past the first loaded message).

Add the Android platform for Capacitor and set up Android builds

Start using semantic commits (and versioning) enforcing

Page search results into, say, 25 per page

Render emoji with Twemoji, and add a emoji picker component

Nested functional components can't render on production builds (nuxt/nuxt#9366)

The intermediate workaround solution is to either inline them, or remove functional, at least until this gets fixed upstream, or Vue/Nuxt 3 comes out, whichever is sooner.

This means:

• Accepting, declining presence subscriptions
• Sending presence subscriptions
• Removing subscriptions
• Caching roster

Occasionally, SET_ROSTER gets called with an empty array. This manifests at the moment with a cascade failure, resulting in UserCard accessing the property of an undefined, crashing the app.

The mutation is called in two (3) places, all in plugins/stanza.js, so this can happen because of two reasons:

1. bind() is triggered with a session resumption, and getRoster() -- as it's known to -- gets an empty array
2. iq:set:roster has two identical handlers, maybe they race condition somehow?

Chat should start scrolled down and retain its scroll position when changing routes.

Most notably, when this happens, avatars flicker (presumably because they reload). This is corroborated by UPDATE_AVATAR being committed to the store.

XMPP presence is broadcast per user resource. This means, effectively, that each device a user has may have a different presence. To help alleviate the issue of picking the appropriate presence data to present to the user, a user may assign integer priorities to each resource.

However, this isn't a definitive solution: multiple resources may have the same priority. And picking 'latest first' isn't much of a solution as there are use cases where priorities are meant to be strictly followed. For example, a JID may belong to a store, with a single high-priority resource representing the store itself, while sub-resources may be individual workers (which may be online outside of work hours, etc.). Such complex use cases make a unique ranking impossible.

So, instead of trying to solve what is an impossible problem, we should aim to provide means to sidestep the issue.

Namely, we should provide multiple ways to rank resource presences, and give the user the option to switch between them. Examples are: 'strict priority order', 'newest first', 'weak priority, most-online', 'most-online'

This isn't an ideal solution, as sometimes the selected algorithm is inaccurate, or we want to see a list view of all resources for another reason. To this end, on desktop, hovering over someone's avatar (or online status dot, etc.), a tooltip with a list of resources and their current online state (and status message) should appear, and a fullscreen dialog or bottom sheet on mobile.

Support for:

• Joining/Leaving MUCs
• Bookmarking MUCs
• Creating/Deleting MUCs
• Editing MUCs
• Moderating MUCs

Replace them with a universal JS implementation, possibly with a global mixin, or at least a custom directive

On non-login pages, there should be a left sidebar displaying info such as:

• Recent chats
• Roster
• MUCs
• Settings
• etc.

The titlebar shouldn't show up on non-Electron targets, like it does now. Furthermore, clicking the titlebar buttons causes an error.

Probably should be part of the <SelfBar/> UI, where everything like this is currently, and probably an option in the settings as well. Ties in with #48 partially

OS has been causing layout issues. Simplebar is equivalent and does not cause these issues.

Big and painful one (maybe). See: nuxt i18n module

Seems to like to do i18n by generating locale-specific routes. Our layouts stay the same though (maybe not for arabic? we could do rtl props everywhere; let's wait to blow up in the muslim world first before worrying about that though -- and let's not even think about all those vertical writing systems, sorry that you get shafted).

But it should also provide a good old locale string database

Also, show dates in timestamps if they aren't from today.

And/or otherwise prevent remounts on chat page components.

Automatically build and create a release on named tag pushes to master

Look into MAM, add old message recovery when possible

Add semantic tag searching a la from:, has:, before: