cabal-club / cabal-cli Goto Github PK

It would be nice if the client would attempt to autocomplete channel names after hitting tab.

For example, one could type:
/j de then hit tab
and it would autocomplete to:
/j default
if there happened to be a default channel in the cabal

used to set a message of the day for a particular channel such as
cabal is a ----NO BURNOUT ZONE---- (shoutouts to @noffle <3)

spec

{
  type: 'chat/motd',
  content: {
    text: 'message of the day for the specified channel',
    channel: 'some channel name. if it didnt exist before, it does now!'
  }
}

it looks like people are having an issue with not seeing any backscroll when they first start cabal up and enter a populated channel

rejoining the channel using /change <channel> fixes it

there's probably some little tweak needed in neat-screen

(maybe we need to attach a listener to self.cabal.db.on('append', cb) & self.cabal.db.on('remote-update', cb) ?)

@cblgh posted https://i.cblgh.org/2018-09/2589Vnp.png, but I only saw the first two lines. Once I restarted my client I saw the rest.

Does everyone in a cabal have the ability to edit and delete each others' messages?

What are the pros and cons of multiwriter hyperdb in this situation compared with a collection of hypercores or hyperdrives like Fritter?

It'd be neat if I ran

cabal --key cabal://abcdef123456 --alias friends

and then I could subsequently run

cabal friends

and have that cabal open.

Some ideas:

• homebrew (macOS)
• pacman (arch linux)
• aptitude (debian)

hyperdb and cabal-node are being referenced in package.json at their github versions, which will cause incompatibility with different installations of cabal depending on when the person installed cabal. It also means incompatibility with other clients (such as Desktop, which depends on particular npm versions).

Can we use npm published versions of these repositories? This also means that we will likely need to advance cabal-node through npm rapidly, but it is better software release practice overall and will improve reliability.

https://github.com/cabal-club/cabal/blob/master/package.json#L15

Bit confused on how to navigate channels and stuff with commands, would be helpful to show some examples!

I'm looking at using cabal for an offline programming camp next year. Without an existing communication channel (ie. email, IM, Slack) I've had to ask people to install airpaste to broadcast cabal keys so that new users can join a cabal.

Realizing that privacy is a concern and things should be private and remain private by default, I was wondering there was interest in adding a second kind of key that would be broadcast on the network using mDNS or UDP?

Given that users expect existing keys and channels to remain private adding a second type rather than an option to broadcast existing keys seemed to make more sense, but I'd be curious to get others thoughts.

If there's interest in this I'd be happy to put together a PR as I"m looking for an excuse to learn more about dat. Please accept my apology if I'm misunderstanding the terminology or architecture.

Thanks for the awesome work! :)

this could be implemented similar to #4 (wrt neat-input at least!)

Simple list of previously entered cli commands with arrow up/down to select

using cabal with --nick <nick> should set the nickname properly

was it due to a malformatted message? a race condition? did someone accidentally fudge up the /default/metadata: {latest: <val>} value?

Typing /na and hitting should autocomplete to /names etc

Now cabal-desktop can put newlines into messages, and they render poorly in the command-line client.

There are some in the #test channel at the moment.

channels that have been created by someone else after the local client has been started aren't visible in the channel sidebar. they become visible once you restart the client

probably an easy fix in either cabal-node or the cli itself

when multiple people are typing in a channel with backscroll that exceeds the window width, the input bar starts disappearing and the cabal header isn't visible

not entirely sure what's going on, but this should be the place to fix it:
https://github.com/cabal-club/cabal/blob/master/neat-screen.js#L41-L57

i don't have time riiight now (but i figured i could post an issue and potentially let someone new to the project create their first PR!) but those of us using cabal have been feeling the need for a way to be notified of when a channel has new unread messages

this would be suuuuuper sweet!

Right now if you try to connect to a key that has no active peers, cabal is trying to connect to it until infinity.

It would be nice to alert the user that there are no peers available and exit the program.

i think one of the current rendering issues has to do with when a line exceeds the terminal width, causing it to wrap to a new row

on rendering we should calculate how many of the visible messages will do this and change the amount of lines we display as a result

e.g.

If there is a way to tell if connected peers are seeders, it would be nice to change the color of their nick or place them at the end of the list so that real user nicks are more prominent.

weechat has a nice feature where names are coloured by hashing a user's name. We could hash each user's public key, which has a nice feature of (statistically) indicating when someone is impersonating someone else by their nick.

I think this really belongs in a common cabal-client module that clients use, but putting it here for now.

Cabals with many messages have issues rendering them properly. Often times the input bar is overwritten, or collides with the backlog and the nick window seemingly has duplicates.

I think these issues stem from bugs in diffy and maybe also from txt-blit (since they are used in combination).

I want to start august's coding off by either finding and defeating these bugs, or by writing a new cli-frontend that doesn't suffer from them.

Rendering issues

• Rendering issues with emojis
• Multi-line pastes not showing up reliably
• Newline-containing messages are not wrapped properly

In the cli.js the cabal-node module is required by your local path. That should be changed! :D

i was thinking about how to replicate chat bugs and thought that since we have every event since the start of a particular cabal we could replay them to simulate a lively chat, and thereby experience bugs in a more reliable fashion.

they way it would work would be to pass a --debug flag when starting the client, to prevent loading all the logs on start and instead make use of hyperdb.createHistoryStream. maybe it can take an offset using time since 2018-08-01 or amount of logs you want to display.

If you start up the CLI interface and it immediately fetches a bunch of new messages, sometimes not all of the new messages will show.

If you quit and restart, the missing messages will be there.

The missing messages can be in the middle, not always at the end of the screen.

I don't know how to reproduce this. It happened after I was offline for about a day. Maybe upon booting and doing a first sync, some of the incoming messages slip through before event handlers get applied which would refresh the screen?

this should be implemented in commands.js using a message posted via cabal-node with the opts.type set to chat/emote

@noffle found this which seems ace, so lets use it
https://github.com/mikaelbr/marked-terminal

The first line of every message is wrapped ok, but subsequent lines (after newlines) extend too far to the right before getting wrapped, overlapping with the peers panel.

I'm not sure if this would work on the current implementation (1 chat => n channels => 1 hyperdb) but I think that it'd be nice to only receive data related to channels you've joined.

The current way that we are getting the channel list will make things slow if there are tons of messages. Also, to get the message list you currently have to filter out the /metadata entry.

If instead, we do /metadata/{channel} and /messages/{channel}/1 we can avoid these issues. Getting the channel list is then iterating on /metadata (which there should only be one per channel).

'names' could mean 'channel names' , and '/change' could mean 'change nick' so it wasn't very clear to me at first which was wich

Not sure if this comes from screen drawing or that the message is indeed received twice (cabal-node)

#24
Looks like it's a rendering issue only.

My working memory is terrible and I forget hotkeys all the time. Having a /hotkeys or /help hotkeys command in the client would be great as right now I always refer to the docs on the website:

https://github.com/cabal-club/cabal#hotkeys

People have been mentioning this in the channels. Just thought I'd create an issue where we can gather some more information. I've created an emoji-test channel.

I noticed that some emojis doesn't cause any rendering issues, and some times it's random. Some other emojis are really consistent.

The telephone for example makes a really predictive pattern:

I propose GPL :)

Some toronto mesh folks (tomeshnet/prototype-cjdns-pi#213) would appreciate this, since it would let them bypass dht and lan routing (since they're usng cjdns) and just connect to known peers directly.

This could be stored in a ${CONFIG}/cabal/config json file, or similar. cabal-client would also be a good place for this.

Users should have some control over the content they see:

• A user may set rules to mute keywords, optionally per user. Ex: /mute [keyword] [username]
• A user may mute another user, such as with a /squelch command.
• A user may mute another user and any mention of them, ex: /shadowban [username] such that it is functionally equivalent to /mute [username] and /squelch [username]
• A user may print their muting and squelching rules. Ex: /rules

Further, moderation controls should be stored as dat archives so that they can also be distributed. Consider:

• A user may print the discovery key of their muted keywords.
• A user may add keyword mutes by discovery key.
• A user may print the discovery key of their squelched usernames.
• A user may add squelched usernames by discovery key.

it'd be really sweet to have a status line that prints when the date has changed, to give some kind of reference or idea of wtf happened since last you checked in

23:59:52 <cblgh> hey lovelies
day changed to 22 Jun 2018
23:59:52 <cblgh> woah that's exactly what we want!

I don't seem (?) to be peering with folks anymore. Creating this issue to track investigation.