cabal-club/cabal-client

interface for writing peer-to-peer chat clients

cabal-client's Issues

Allow mods to archive channels

I think it makes sense to bundle channel archiving within the current mods/admins system. It could be used to clean-up channel listings from accidentally made channels, or to hide vulgarly named channels.

Question: where does this functionality make the most sense—in cabal-client or cabal-core?

Example commands:

/archive <channel>
/unarchive <channel> (alt. /restore <channel>)
/archives (lists all archived channels, the archiver (good idea?), and the stated reason for archiving)

older issue on this topic: #16

Export / Import database feature

It would be nice to have a mechanism to export a portable snapshot of the database (in json?) for backups or migration to another cabal.

And likewise, it would be nice to have a way to import a dataset into a cabal.

Show status messages in the !status buffer

Saw this today on the public cabal:

14:59:39 <eea2c604> oops, does the help message display for the whole channel, or just me?

I've found this confusing too at different times. Weechat, for example, will show status messages ONLY in the status buffer. I think this makes sense for command output like /help and /channels in particular.

offline messages?

If a user goes offline then receives messages do they see them when back online and can they then deal with them and delete them after?

Add ability to mute unread count / mentions

with the advent of the https://github.com/cabal-club/cabal-bot github integration, i found a need to mute notifications / new channel activity

that is, i want to be able to peek at the github channel, at the same time i don't want it to show that it has new messages, or that i have been mentioned in it. it's just a bit stressful / not useful for channels with a lot of activity and/or automated feeds as in the github integration case

JSDoc?

There are loads of methods in the README . If I were to rewrite these as JSDoc strings in the code, then set up an npm task for building documentation HTML, would that be useful work? It might make developing against this a bit easier (enabling intellisense etc).

Add method to publish file

Unread tracking could happen in the p2p database

Then your unread state would be maintained across multiple clients and computers (if we eventually implement sameAs to link those accounts together)

Also then we'll know what messages have been read by others. Clients could show read receipts in the UI, which is really nice to have in smaller channels.

Barebones implementation

i think one way to get started with the cabal-client interface is to simply export a javascript object which can save various settings in its keys

module.exports = {}
...
var client = require("cabal-client")
client["cabal-desktop"] = {notifications: "none"}

mainly writing this down as a note for myself for an upcoming evening of implementation :)

Terminate cabal-core & swarm on _destroy

Are the cabal-core and the swarm also being terminated? Otherwise it'll continue peering and indexing.

(If this is non-trivial, we can make an issue & a future PR!)

Originally posted by @noffle in https://github.com/_render_node/MDE3OlB1bGxSZXF1ZXN0UmV2aWV3Mjc2Mjg4OTYz/pull_request_reviews/more_threads

Enable pluggable networking

Just a thought: eventually it'd be great if we could move out the networking elsewhere, maybe a pluggable set of modules, so that regardless of whether you're doing node/electron/web/mobile, you can use the discovery methods that work for that platform.

Originally posted by @noffle in https://github.com/_render_node/MDE3OlB1bGxSZXF1ZXN0UmV2aWV3Mjc2Mjg4OTYz/pull_request_reviews/more_threads

handle command processing

This way each client doesn't need to implement emotes, etc

Add method for joining many cabals

Cabal client is still a bit rough to get going with, people resort to reading the cabal-cli source as the canonical documentation.

One thing that could help is extracting the logic for joining many cabals, which is a common enough usecase that it should just be supported outright.

from cli

  var pendingCabals = args.new ? [client.createCabal()] : keys.map(client.addCabal.bind(client))
  Promise.all(pendingCabals).then(() => { /* do stuff */ })

Save per-client settings

cf #4, i'm anticipating the need for settings so that people can e.g. choose the granularity of their notifications (no notifications; respectful (new message|mentions); full-on push notifications)

like @cinnamon-bun discussed we can save this in cabal-client on a per-client basis

Disambiguate help command

The output from the /help command is pretty massive.

By refactoring it, we could split it into segments such as:

• basics
• moderation
• channels
• sharing
• misc
• hotkeys (client specific, e.g. cabal-cli will have its own, cabal-desktop other hotkeys, if any)

web: stores seem to be getting merged

investigate why information from different cabals seem to exhibit the behaviour of being merged into one and the same (e.g. look at one cabal, see the information from another cabal you have data stored from locally)

could be that something more needs to be set on https://github.com/random-access-storage/random-access-web to get the desired behaviour

try to replicate

• using only RAW + a reproduction test script
• in firefox
• in chrome

Build for web browsers?

I know cabal is based on Dat and Dat has an sdk that is supposed to work for browsers.
Would cabal-client work for browsers too? Any plans to provide a build?

Generate Typescript definitions from JSDoc

See discussion on cabal-club/cabal-core#110.

This should be possible, but cabal-core is the main dependency for cabal-client. If cabal-core doesn't have type declarations, type declarations for cabal-client will be much worse, or possibly completely broken.

`init` event should wait the for indexer before before firing

On a client, calling functions like cabalDetails.getUsers() immediately after the init event would return an empty set of users/channels/etc. Waiting a few seconds, then cabalDetails.getUsers() does have content.

from @okdistribute:

ideally this should be a 'ready' event from some lower-level module, i bet it will need to come from the indexer -- which should already be there somewhere. a timeout will give different results on different computers, slow computers or those with spinning disks might not be able to complete the necessary steps in 2 seconds with large cabals

Show join & leave messages

Ideally configurable, it would be useful to see in the chat history when people join and leave channels you're in. For cabal-client, this could be events, or virtual messages like the moderation status messages we do.

Share cabal key over peer-defined hyperswarm topic

cblgh:
i've been dreaming lately of integrating paperslip, my hyperswarm sharing thing, into cabal-client

so to share a cabal key in cabal desktop you would just like

/share nicks-secret-gang

then you shout across the room or send me a text "HEY JOIN nicks-secret-gang IN THAT INPUT BOX!" and i do that in my cabal-desktop

so i use that phrase as a [hyperswarm] topic by which the cabal key is transmitted

nick: and take the phrase and set it as the alias for convenience

implement channel management commands

i want to manage which channels come up in listings, and invite people to them so that they don't miss out on its existence. cabal-client should implement functionality to make the following operations possible in the cli:

/hide <channel-name> which hides it when i list /channels, unless a flag is present e.g. /channels --all

/archive <channel-name> which hides it for everyone when they list /channel
a message could be printed in the channel:

cblgh has archived this channel. type /unarchive to restore

/invite <pubkey> <channel-name> where pubkey is the peer i want to invite to <channel-name>

• or /invite <nick> <channel-name> where every peer that currently has the name <nick> is invited
• multiple peers should be able to be invited at the same time too, and with autocomplete for nicks

Idea: A method for storing / loading general client settings

Something like

client.getSettings()
client.saveSettings(settingsObject)

Where settingsObject is an arbitrary JSONable object.

This would be for local client settings like notification options, color themes or light mode vs dark mode, auto-emojification, etc.

How does this handle multiple clients on the same machine?

Are all clients on a machine meant to share the same local storage for their Client instances?

If not, they could specify a name so they could have their own separate local storages.

var client = Client(cabal, "my-awesome-client")

Shim out fs access

we recently had a pr that added a much-welcomed settings file (#89) however, as @khubo recently realized, this is fudging up cabal when used in the browser!

so we need to extract the settings logic into something that can work in the browser. so rather operate on the path using something that relies on the random-access-* ecosystem (like we're already doing in src/storage-node.js / src/storage-browser.js)

implement file sending

see cabal-client-files for @nikolaiwarner initial implementation

• keep track of files sent per per, allow querying
• index by file type, file name

images

mostly ux ideas

• allow sending many images at once
• ability to group images into an album (i.e. all 15 files i dragged at the same time should be marked as a group somehow) signal on mobile has a nice ux for for this, also mastodon too
• ability to add alt text. any peer should be able to reference an image and add alt text for vision impaired, spreading out the burden of helping others. see the topic view for one way of implementing this
• erase exif data by default (add override boolean)

Mechanism for creating chat history from multiple sources

Ideally we'll want to show messages from several cabal-core views:

• chat messages
• nick changes
• moderation actions
• joins/parts

Add ability to store/load unread count

Currently, the count of unread messages is not persisted. Because of that, unread notifications will vanish after a restart. This would be nice to have, maybe as an opt-in.

Might have a loose connection to #45.

Display moderation actions in more cases

Right now we only show notifications for moderation actions when the person doing the action is a mod/admin of yours. I think it would also be nice to know:

• when someone hides/blocks you
• when someone makes or removes you as mod/admin

cc @RangerMauve, who brought this up.

Fix timing issue of new slash commands output

repro'd using a cabal-cli client while joined to 3 cabals in the same client

implement invite to channel

if we have a method that takes a user name and returns a list of public keys i'm thinking it can be used for a facility that allows for inviting users into channels e.g.

   /invite <name> <list of channel names>

extracted from #16 :

/invite where pubkey is the peer i want to invite to

or /invite where every peer that currently has the name is invited
multiple peers should be able to be invited at the same time too, and with autocomplete for nicks

Idea: search for messages

Something like

client.searchMessages({
    // various optional query settings:
    text: 'blah',  // case-insensitive substring match or fuzzy match
    channel: 'foo',  // limit to one channel?
    author: 'bar',  // limit to one author?
})
--> list or stream of matching messages, most recent first

Moderation command that shows who views me as {mod,admin,hidden,etc}

e.g.

> /appears-as
Sees you as an admin:
cblgh.abcd
Sees you as a moderator:
foo.a123
Sees you as hidden:
bax.dff2

Add easy examples

It would be great to have something like https://github.com/kappa-db/workshop but for writing your own client with cabal-client. A small set of clearly delineated examples would help, too :)

Something like https://github.com/cabal-club/cabal-bot is a good start :~

thanks @timgoeller for the idea :)

New messages don't trigger `new-message` event

Haven't had the time yet to really check why this happens, but it seems to be caused by this commit: 1dbd522 (everything works when I revert these changes locally)

If I join a cabal I will receive all historical messages, but not any of the new messages (or at least the event won't be triggered for new messages). This happens even when I join these channels after I've joined the cabal.

Implement audio/video streaming

As demonstrated by hypervision it is possible to stream video over hypercores. This has wondrous implications for a chat application like Cabal, as it makes possible group voice chats à la TeamSpeak, and video chats à la Zoom or Jitsi, all P2P.

See also: #15

Idea: emoji conversion

Provide some helper functions to convert between actual emojis and :emoji_codes: for clients to use when posting or when displaying.

See this issue in cabal commons for details

improve granularity of listeners

khubo and nick, and myself while starting to patch cabal-irc, have felt a need to have more granular listeners than on("update")

as an example: this method, from cabal-desktop, would be split up into several listeners

i haven't had a sit down to think properly about which ones yet but maybe:

• "new message", channel
• "join/leave channel", channel does this need to be disambiguated? one event type for the person who is running the client; the other event type for when other peers join or leave specific channels?
• "nick change", {userkey, newnick}
• "topic", channel, topic, maybe just a channel state changed event? that includes new people joining/leaving and topics changing.
• "initialization", this fires basically when all data is available after first starting up a client. it is only triggered once

it could also be interesting to include a delta, the change in state that occurred in the current update, that can optionally be used (that way client implementations don't necessarily need to be in a reactive framework like react or vue. introducing a delta could however cause weird errors stemming from out of order updates.

@khubo @nikolaiwarner chime in on your recent impressions and thoughts when developing cabal-desktop so excellently these past 2-3 weeks. which specific cases were aching for more granular listeners?

NPE when starting a new private message conversation

steps to reproduce:

• start a new Cabal so you have no chat history with yourself
• send a PM to yourself

events for managing cabals

Currently all events are at cabal level, and there is no events emitted for adding/joining/removing cabal etc. It would be dope if we could have some events for the same at client level. Events on top of my head is:

• joining cabal
• creating cabal
• leaving cabal

Write API documentation for Moderation class

see #50 for the files needed to document