profile
viewpoint

browserify/browserify 13316

browser-side require() the node.js way

browserify/browserify-handbook 4435

how to build modular applications with browserify

browserify/watchify 1767

watch mode for browserify builds

browserify/resolve 592

Implements the node.js require.resolve() algorithm

browserify/brfs 550

browserify fs.readFileSync() static asset inliner

browserify/browserify-website 548

the code that runs http://browserify.org

browserify/factor-bundle 403

factor browser-pack bundles into common shared bundles

browserify/webworkify 394

launch a web worker that can require() in the browser with browserify

browserify/detective 377

Find all calls to require() no matter how deeply nested using a proper walk of the AST

browserify/http-browserify 234

node's http module, but for the browser

push eventpeermaps/eyros

substack

commit sha 016fb49f2428a70a5c3d96f723fa0680ac8a2ff5

forward and format errors

view details

push time in 3 days

push eventpeermaps/eyros

substack

commit sha 77519ef208d692c2e67f87eda45f5390ea5f9c70

wasm storage compiles

view details

push time in 3 days

pull request commentcabal-club/cabal-core

authenticate swarm connections with a verification hook

The noise public key is often ephemeral and is not the same as the hypercore feed key used to author messages and identify participants.

substack

comment created time in 5 days

push eventpeermaps/eyros

substack

commit sha 0913714bce8928ceacffd52f3ff7406e1cae8b38

wasm browser storage stub

view details

push time in 21 days

create barnchpeermaps/eyros

branch : wasm-async

created branch time in 23 days

issue commentpeermaps/eyros

async

The async branch passes all tests.

substack

comment created time in 24 days

issue closedpeermaps/eyros

variable sized payloads with u16 or u32 length

This is likely already possible with a custom serialization implementation, but it would be nice to have some examples. 8 bytes of length data is overkill for variable-sized payloads that have a known maximum size.

closed time in 24 days

substack

issue commentpeermaps/eyros

variable sized payloads with u16 or u32 length

This feature was added with the switch to desert.

substack

comment created time in 24 days

issue closedpeermaps/eyros

move from RandomAccess to core traits

but this needs to be done in a way that will work with browser storage in wasm

closed time in 24 days

substack

issue commentpeermaps/eyros

move from RandomAccess to core traits

sticking with RandomAccess for now because it's going to make wasm support easier

substack

comment created time in 24 days

push eventpeermaps/eyros

substack

commit sha 86e8bc96fd695938a29878f8c7c657fadf5999ef

updated tests and docs for async

view details

push time in 24 days

push eventpeermaps/eyros

substack

commit sha 2a7ed0907b65773e92cf7b29e768660f0cad320d

indirect Storage trait and it compiles again finally

view details

push time in 25 days

push eventsubstack/parse-bga-mesh

substack

commit sha 08603d81dc6410be4b15bce2fe4063ef7578f95c

also ignore glb and gltf files

view details

substack

commit sha 92d1ef49e442e2266dfafbd8873bc8855d0730ea

2.0.2

view details

push time in 25 days

PR merged peermaps/eyros

Unpin futures

This fixes some of the errors on the async branch. Thanks!

+28 -28

0 comment

4 changed files

yoshuawuyts

pr closed time in a month

push eventpeermaps/eyros

Yoshua Wuyts

commit sha ad2a3fe9551cc719123ceb39a4908414997bfbd0

Unpin futures

view details

substack

commit sha d03c7cb01b4f69f6a9858dceed1d5caacfc6ed02

with box errors

view details

substack

commit sha f774290c5ec1e7cde687be9101dacc129169ace2

convert to boxed std error type

view details

push time in a month

pull request commentcabal-club/cabal-client

network blocking

This patch doesn't yet delete the remote feed and refuse to replicate it again. That is the second part of implementing this feature fully which will require some changes upstream in multifeed.

substack

comment created time in a month

startedgarbados/pouchdb-hypercore

started time in a month

PR opened cabal-club/cabal-client

network blocking

This patch uses the swarm opts.verify hook and cabal.removeConnection() to implement network-level blocking of peers. This is only part of what we'll need for a full implementation of blocking since you can still get the content from blocked peers via other peers. I also had to make some room in the command-handling to support blocks as well as other arbitrary flags. Before these changes any flags that weren't hide/unhide wouldn't show up correctly.

depends on https://github.com/cabal-club/cabal-core/pull/96

+104 -55

0 comment

5 changed files

pr created time in a month

create barnchcabal-club/cabal-client

branch : network-block

created branch time in a month

push eventcabal-club/cabal-core

substack

commit sha b855c60e980152d6b2d3ad834f3eacb332f7fd9a

removeConnection() method and save the info instance from the swarm

view details

push time in a month

push eventcabal-club/cabal-core

substack

commit sha b4d51d8b8e0a455dbb1881ea363030392b2588cb

verify() should receive a hex string and fix bug not adding connection correctly

view details

push time in a month

PR opened cabal-club/cabal-core

authentication swarm connections with a verification hook

This patch is a protocol-level breaking change that authenticates clients by signing the noise handshake hash with the provided public key. Previously with the custom peer-id extension peers would send their id but there was no verification that a peer was who they reported to be.

On top of this verified peer id, there is a hook available by passing in an opts.verify() function that receives the remote public key and a callback to reject or allow a connection from a remote peer. In cabal-client we can use this hook to do network-level blocks and also to implement the first part of invite-only cabals.

+170 -16

0 comment

4 changed files

pr created time in a month

push eventcabal-club/cabal-core

Diana Thayer

commit sha 88b32cf72250ede654d9fe93f10dfddce016be39

Document possible flags for `listByFlag` Flags are an oft-referred to concept but they aren't enumerated in the documentation. Per a coversation in the default cabal: ``` <kira> right now each user can have flags from set of ["hidden", "admin", "mod"] <kira> per user perspective ```

view details

Diana Thayer

commit sha aa5dac5b2b339cc588dee751bf89cb9632528d12

update readme to indicate flags used by cabal-core

view details

Kira Oakley

commit sha 2f41eb575ddbc1644dd113f42c361101bcca9431

Merge pull request #94 from garbados/patch-1 Document possible flags for `listByFlag`

view details

substack

commit sha 309ea5c2ef9ca6dbf31c5ce178d00847061677c2

Merge branch 'master' of github.com:cabal-club/cabal-core into swarm-auth-hook

view details

push time in a month

create barnchcabal-club/cabal-core

branch : swarm-auth-hook

created branch time in a month

PR opened kappa-db/multifeed

allow replicate() to accept an existing hypercore-protocol instance

This patch aligns multifeed's replicate method with hypercore's replicate(), where it's possible to take over replication from an existing hypercore-protocol instance. This way we can support schemes where there is some verification process over extension messages before replication begins.

+149 -8

0 comment

3 changed files

pr created time in a month

create barnchkappa-db/multifeed

branch : existing-protocol

created branch time in a month

created tagsubstack/hypercore-authenticate-session-extension

tag1.0.1

hypercore extension to verify the identity of peers by signing the noise key with another key

created time in a month

push eventsubstack/hypercore-authenticate-session-extension

substack

commit sha 2391e9c50ecd2b1baa252f2991bc5210a8bc2733

more helpful error message if handshakeHash not found

view details

substack

commit sha 1430f0a2f11ff9e714a670b5cc2c0e27636c7271

1.0.1

view details

push time in a month

push eventsubstack/hypercore-sign-noise-key-extension

substack

commit sha 9e7745c8a333e173be1bbd189f2995a5ada9360b

rename project and use handshake hashes

view details

push time in a month

PR opened mafintosh/simple-hypercore-protocol

expose handshake hash

This patch exposes the handshake hash, which the noise docs indicate uniquely identifies the noise session and can be signed or hashed with a password to generate authentication tokens.

+39 -0

0 comment

3 changed files

pr created time in a month

create barnchsubstack/simple-hypercore-protocol

branch : expose-handshake-hash

created branch time in a month

create barnchsubstack/hypercore-sign-noise-key-extension

branch : main

created branch time in a month

created tagsubstack/hypercore-sign-noise-key-extension

tag1.0.0

hypercore extension to verify the identity of peers by signing the noise key with another key

created time in a month

created repositorysubstack/hypercore-sign-noise-key-extension

hypercore extension to verify the identity of peers by signing the noise key with another key

created time in a month

pull request commentcabal-club/cabal-core

Document possible flags for `listByFlag`

The flag is "hide".

Flags can be more than just those values, but presently those values are connected to behaviors. You could use other tags for example to designate that a user is a bot or that a user is a seeding node, not meant to be addressable by tab completion.

The behavior of "admin" and "mod" has a special significance in the underlying moderation module: https://github.com/substack/materialized-group-auth

garbados

comment created time in a month

pull request commentcabal-club/cabal-core

duplexify must be in object mode for mod streams

Thanks for the patch! This has been merged into 13.0.2.

garbados

comment created time in a month

PR merged cabal-club/cabal-core

duplexify must be in object mode for mod streams

This is a WIP PR because I am unfamiliar with the testing suite, so it only fixes my problem presently.

The issue is that if you treat cabal.moderation.list as a read stream instead of utilizing its callback, you get this:

Uncaught TypeError: The "chunk" argument must be one of type string, Buffer, or Uint8Array. Received type object
      at chunkInvalid (node_modules/readable-stream/lib/_stream_readable.js:313:10)
      at readableAddChunk (node_modules/readable-stream/lib/_stream_readable.js:258:31)
      at Duplexify.Readable.push (node_modules/readable-stream/lib/_stream_readable.js:241:10)
      at Duplexify._forward (node_modules/duplexify/index.js:172:26)
      at Readable.onreadable (node_modules/duplexify/index.js:136:10)
      at emitReadable_ (node_modules/read-only-stream/node_modules/readable-stream/lib/_stream_readable.js:504:10)
      at emitReadable (node_modules/read-only-stream/node_modules/readable-stream/lib/_stream_readable.js:498:62)
      at addChunk (node_modules/read-only-stream/node_modules/readable-stream/lib/_stream_readable.js:298:29)
      at readableAddChunk (node_modules/read-only-stream/node_modules/readable-stream/lib/_stream_readable.js:278:11)
      at Readable.push (node_modules/read-only-stream/node_modules/readable-stream/lib/_stream_readable.js:245:10)
      at Readable.ro._read (node_modules/read-only-stream/index.js:22:16)
      at DestroyableTransform.<anonymous> (node_modules/read-only-stream/index.js:15:16)
      at emitReadable_ (node_modules/readable-stream/lib/_stream_readable.js:538:12)
      at processTicksAndRejections (internal/process/task_queues.js:83:21)

Here's an excerpt from the source that triggers the issue:

const modStream = cabal.moderation.list()
modStream.on('data', (action) => {
  console.log(action)
})

The problem is, apparently, that duplexify must be in object mode to handle the objects produced by the stream. This is accomplished by changing duplexify() into duplexify.obj()

+24 -2

1 comment

2 changed files

garbados

pr closed time in a month

push eventcabal-club/cabal-core

Diana Thayer

commit sha 9ab9c74c8a219f1415ba75e9443bfdde0532272c

duplexify must be in object mode for mod streams

view details

substack

commit sha e3e35072c02c30bb90538927bd29b5ee0837ef78

13.0.2

view details

push time in a month

created tagcabal-club/cabal-core

tagv13.0.2

Core database and replication for cabal.

created time in a month

push eventpeermaps/eyros

substack

commit sha eef3cab1fd266e0336152cb88cf1dbdf333997b6

unfold impl

view details

push time in 2 months

push eventpeermaps/eyros

substack

commit sha 09edf53c21ca8e51992d670c55c56e94e4e1de82

messed up this commit

view details

substack

commit sha 50f737b118af743b5692893f6200c333f2b5b596

current state

view details

substack

commit sha 434c05f4eb795e48f1f12ee0be520eef09b25c4c

fixed commit

view details

push time in 2 months

issue commentcabal-club/commons

New website

We can use some copy and art assets from the zine https://substack.net/zine/cabal.html

noffle

comment created time in 2 months

issue commentcabal-club/commons

moderation mvp

mozilla mvp cabal demo

outline

  1. brief intro about cabal and the subjective moderation system
  2. as user A: create a new cabal
  3. as user A: send a link to friends with user A as the mod
  4. as user B (not presenting): post a spammy message
  5. as user A: ban user B for being a spammer
  6. as user C (not presenting): say that cats are good
  7. as user A: ban user C for saying that cats are good
  8. as user D: undo the previous ban from user A
  9. as user E: set mod key to user D. show how user C reappears
  10. as user E: add user C as a moderator
  11. discuss findings from user research and cblgh thesis
  12. close

intro notes

  • no servers, no accounts, offline and works over the internet or a local network
  • longevity: infrastructure and social
  • subjective moderation: everyone is an admin, from their perspective
  • anyone can step up to perform moderation work
  • when you share a link, you share a moderation key to ensure the new person will have a good onboarding experience

logistics

  • the presenter will have 3 accounts for users A, D, and E
  • other team members not presenting will be users B and C
  • presenter will use a mix of clients: desktop and cli
  • other team members not presenting will join the cabal and add messages
substack

comment created time in 2 months

issue commentcabal-club/cabal-desktop

Stuck on loading screen in v6.0.2

This also looks like what happens to me when I run the latest desktop with npm start: no errors in the console or in the debugger window. The screen just shows "Loading hypercores and swarming..." and gets stuck there.

cjdesno

comment created time in 2 months

CommitCommentEvent

issue commentRangerMauve/hyper-presence

Cabal support

It seems that the await is unnecessary here? p.setData() can be queued and events will happen in the future anyways. And you can check p.peers during a state change event.

const p = await Presence.start(somehypercore, {
  id: Buffer.from('A', 32)
})
p.setData({something: 'whatever'})
p.on('peer-found', (peer) => peer.data)
p.on('peer-removed', (peer) => peer.id)
for(let peer of p.peers) {
  console.log(peer.id, peer.data, 'connected to', peer.connectedTo)
}
cblgh

comment created time in 2 months

issue commentRangerMauve/hyper-presence

Cabal support

I think it's better to not take a hypercore or hypercore-protocol instance for this but instead return an object that can be fed into feed.registerExtension(name, ext) or proto.registerExtension(name, ext).

This is what I did for hypercore-query-extension: https://github.com/peermaps/hypercore-query-extension/#qextension

This will work for hypercores and hypercore-protocol instances and gives users of this module more flexibility with naming schemes.

cblgh

comment created time in 2 months

push eventpeermaps/eyros

substack

commit sha 105a549ae3b916dc8344b922205b1e1f9ffde40c

fixed stream using unfold from the futures crate

view details

substack

commit sha ce1e5708076ff31abeab7914a6e3435f6485c322

main lib compiles async finally

view details

push time in 2 months

PR closed substack/desert

Format code using 'cargo fmt'
+1020 -805

0 comment

5 changed files

Atul9

pr closed time in 2 months

PR opened cabal-club/cabal-cli

fixes to look better with a light bg

With the new peer list the names are hard to read with a light background and also the contrast could be a bit higher for some items with a dark background too.

Before:

before-light

before-dark

After:

after-light

after-dark

Plus I tested with a few other combinations of light and dark backgrounds and I think these strike a good balance. Longer term it probably makes sense to have a light mode vs dark mode setting, especially for setting the nick colors but until then (and still for the unconfigured default version) I think it's better to go with settings that work better on a variety of configurations.

+6 -8

0 comment

2 changed files

pr created time in 2 months

create barnchcabal-club/cabal-cli

branch : fixes-for-light-bg

created branch time in 2 months

push eventcabal-club/cabal-core

substack

commit sha e233483dd36957a77699a4ed40af1c3526553e7b

fix skipped failing tests

view details

push time in 2 months

PR merged cabal-club/cabal-core

listModerationBy

This secondary index and moderation API is required to make /inspect from the roadmap work.

The patch adds a listModerationBy(key) method which streams primary documents associated with moderation actions for a given user.

+67 -13

0 comment

3 changed files

substack

pr closed time in 2 months

push eventcabal-club/cabal-core

substack

commit sha 3861da278c6d73081749003ef5c6e41fa16c5e89

listModerationBy function and secondary index

view details

substack

commit sha eec03f7d92006f676c3b8295dbadb23bca3bd95c

Merge branch 'master' into list-moderation-by

view details

substack

commit sha 1e0a8a8d8a8a51527d627d98130c7ae543223eaa

document listModerationBy

view details

substack

commit sha 97b91c84887cf121d4ca30ca2f15016b17f3b2b0

Merge branch 'master' of github.com:cabal-club/cabal-core

view details

substack

commit sha a96c9599cf19c7718be5fe0cd71eb7d383bd7037

11.2.0

view details

push time in 2 months

created tagcabal-club/cabal-core

tagv11.2.0

Core database and replication for cabal.

created time in 2 months

pull request commentcabal-club/cabal-client

Improve mod commands

The /inspect implementation depends on cabal-core/#87.

cblgh

comment created time in 2 months

push eventcabal-club/cabal-client

substack

commit sha 75a2fb2f99dd127f6ac312f29b26da29ef87b670

inspect command

view details

push time in 2 months

PR opened cabal-club/cabal-core

listModerationBy

This secondary index and moderation API is required to make /inspect from the roadmap work.

The patch adds a listModerationBy(key) method which streams primary documents associated with moderation actions for a given user.

+67 -13

0 comment

3 changed files

pr created time in 2 months

push eventcabal-club/cabal-core

substack

commit sha 1e0a8a8d8a8a51527d627d98130c7ae543223eaa

document listModerationBy

view details

push time in 2 months

create barnchcabal-club/cabal-core

branch : list-moderation-by

created branch time in 2 months

PR merged cabal-club/cabal-core

use admin for admins, instead of mod

we were mistakenly setting the administrator role using the passed in moderator key, this PR fixes that

in a future PR we should also set all of the passed in admin & mod keys, but it's 22:11 atm and i don't trust myself to implement new stuff that late :^)

+169 -40

1 comment

3 changed files

cblgh

pr closed time in 2 months

created tagcabal-club/cabal-core

tagv11.1.0

Core database and replication for cabal.

created time in 2 months

push eventcabal-club/cabal-core

cblgh

commit sha 14167e31122c9cd88839f0a63d6fbafdbb533de1

use admin for admins, instead of mod

view details

substack

commit sha 3cda999bf9b139dc8dd916018eb9f035dc750550

test for setting multiple admins and mods in the cabal addr

view details

cblgh

commit sha 8e27c3786d181c98136078f4d85eeb23d04df2eb

use admin for admins, instead of mod

view details

cblgh

commit sha b4d6463efd6a71426364781b22762f719b2738ed

Merge branch 'use-admin-not-mod' of github.com:cabal-club/cabal-core into use-admin-not-mod

view details

substack

commit sha 04cf3353a54c9bf0819d758b0556f895e8acf79c

fixes for admin and mod keys in cabal urls

view details

substack

commit sha 2e60cffae3169ba7bf81db8aa18c82e40bb2089d

fix merge issue

view details

substack

commit sha 779a500c5d2f3b6fb4e75c5a98af96389cfe9a8e

11.1.0

view details

push time in 2 months

Pull request review commentcabal-club/cabal-core

use admin for admins, instead of mod

 var { nextTick } = process  module.exports = function (cabal, db) {   var events = new EventEmitter()-  var modKey = cabal.modKeys[0]+  // TODO: use *all* keys from cabal.adminKeys, and cabal.modKeys

this is fixed with the patches i added

cblgh

comment created time in 2 months

push eventcabal-club/cabal-core

substack

commit sha 3cda999bf9b139dc8dd916018eb9f035dc750550

test for setting multiple admins and mods in the cabal addr

view details

substack

commit sha 04cf3353a54c9bf0819d758b0556f895e8acf79c

fixes for admin and mod keys in cabal urls

view details

substack

commit sha 2e60cffae3169ba7bf81db8aa18c82e40bb2089d

fix merge issue

view details

push time in 2 months

push eventpeermaps/eyros

substack

commit sha dd3b7b713f4036aee1eb26381228d9065669b153

still not compiling

view details

push time in 2 months

created tagcabal-club/cabal-core

tagv11.0.1

Core database and replication for cabal.

created time in 3 months

push eventcabal-club/cabal-core

substack

commit sha 4c17ace1105dab59d07db46fb1dd8d6bc849228b

failing test case for adding then removing a block

view details

substack

commit sha a98ac48545c44d19b347784de09132de19b71a24

fix remove flag for moderation

view details

substack

commit sha e75bd67db9938848d1c8d6064181c7820c9c208c

11.0.1

view details

push time in 3 months

push eventcabal-club/cabal-client

substack

commit sha d7f72cb7a467121f466f0b2308e88c8c838f1d67

use cabal-core 11.0.0

view details

push time in 3 months

PR merged cabal-club/cabal-core

moderation based on flags

This is an alternative to #80 using the flag approach that landed in materialized-group-auth 2.0.0. This approach streamlines much of the handling and supports blocks, hides, mutes, as well as other flags that might be required depending on the user feedback for moderation.

Instead of dedicated methods for block()/unblock() etc, you can add and remove arbitrary flags with setFlags()/addFlags()/removeFlags().

+480 -172

0 comment

5 changed files

substack

pr closed time in 3 months

created tagcabal-club/cabal-core

tagv11.0.0

Core database and replication for cabal.

created time in 3 months

PR merged cabal-club/cabal-core

add support for mod & admin keys in cabal key uri

this PR adds basic support for Cabal URIs containing mod & admin keys, e.g. cabal://[0-9A-Fa-f]{64}?mod=<key> and is related to https://github.com/cabal-club/cabal-client/pull/41

+23 -19

0 comment

3 changed files

cblgh

pr closed time in 3 months

push eventcabal-club/cabal-core

substack

commit sha a699e32026abe18855f884eedfc39b7ce05078a5

moderation based on flags

view details

substack

commit sha d64a24d4214e31f11288e416c45a998cfccf4a26

moderation.list() with additional cross-channel test and some fixes

view details

substack

commit sha 4dea82e46155a769f2f2d7270f01d8223b9bd2eb

Merge branch 'master' of github.com:cabal-club/cabal-core into mod-flags

view details

substack

commit sha 541d2e126bd9d20adebc6a3a7c8d6a78359d552f

pass through additional fields when setting flags

view details

cblgh

commit sha f02352a21cd1b18d596698cfee4f5ae37a7204e2

add support for mod & admin keys in cabal key uri

view details

substack

commit sha 7118a5cc5b057767fe48da207e19860775b9f33e

Merge branch 'mod-key-v2' of github.com:cabal-club/cabal-core into mod-key

view details

substack

commit sha ae7ea34482ad21e42113d722cb4b39f41c50c343

use modkey from url

view details

substack

commit sha 330aff8ce6c101ed76c5985dba828c9631633912

11.0.0

view details

push time in 3 months

pull request commentcabal-club/cabal-client

Improve mod commands

updated to track the latest set of commands[1] with the cabal-core flags implementation[2]

  • [1] https://gist.github.com/cblgh/19562550a3512d8c50ecf30f3c4c32e7
  • [2] https://github.com/cabal-club/cabal-core/pull/83
cblgh

comment created time in 3 months

push eventcabal-club/cabal-client

substack

commit sha d020cd0c0693aeae8851d947c781524d28f7be3e

update commands to match commands gist. un-commands not completely working yet, others TODO'd

view details

push time in 3 months

push eventcabal-club/cabal-core

substack

commit sha aac5ed4e37a3da6d3bfe837a41c259e594644e9a

remove package-lock.json

view details

Alexander Cobleigh

commit sha 736cd7319312a41d2d154d7199f3e27614b3b99c

Merge pull request #84 from cabal-club/rm-package-lock remove package-lock.json

view details

substack

commit sha 4dea82e46155a769f2f2d7270f01d8223b9bd2eb

Merge branch 'master' of github.com:cabal-club/cabal-core into mod-flags

view details

substack

commit sha 541d2e126bd9d20adebc6a3a7c8d6a78359d552f

pass through additional fields when setting flags

view details

push time in 3 months

push eventcabal-club/cabal-client

substack

commit sha 01ba1c11ee9c57ff33fef8b87b7ccb88bd406487

cannot join @, trim leading #s, /part alias

view details

push time in 3 months

push eventcabal-club/cabal-client

substack

commit sha 49704ecdb23ed65206c20d15b8522c7cc8a1a775

updated to use flag-based cabal-core moderation patch #83

view details

push time in 3 months

PR opened cabal-club/cabal-cli

initialize state.collision

It's possible for state.collision to be checked before an update comes in that initializes the value, which can crash the program.

+1 -0

0 comment

1 changed file

pr created time in 3 months

create barnchcabal-club/cabal-cli

branch : state-collision-fix

created branch time in 3 months

PR opened cabal-club/cabal-core

remove package-lock.json

When users install this package with npm, they will not get the versions pinned in the lockfile and will instead get the latest versions matching the semver for dependencies. This makes it very easy for versions between local dev and from npm install to diverge significantly. The lockfile is also used by CI, so updates to package.json versions have no effect for CI, but including changes to package-lock.json introduces a lot of noise to patches and makes pull requests not trivially composable as it's very easy to introduce merge conflicts with files that are modified by programs.

+2 -12692

0 comment

2 changed files

pr created time in 3 months

create barnchcabal-club/cabal-core

branch : rm-package-lock

created branch time in 3 months

PR closed cabal-club/cabal-core

unban+admin

This patch builds on #78 and #77 and adds:

  • unban
  • addMod
  • removeMod
  • addAdmin
  • removeAdmin
  • moderation.getRole
  • moderation.modInfo
  • moderation.listMods
  • moderation.listAdmins
+364 -44

4 comments

5 changed files

substack

pr closed time in 3 months

pull request commentcabal-club/cabal-core

unban+admin

closing in favor of #83

substack

comment created time in 3 months

PR closed cabal-club/cabal-core

moderation.banInfo

This patch does some internal reorganization to the fields that listBans() returns so this is a breaking change. But with this change, you can set additional properties such as a reason for a ban message:

      cabal0.publish({
        type: 'ban/add',
        content: { key: key1, reason: 'spammer' }
      })

and then later or on a different synchronized cabal you can read that information back using banInfo():

          cabal2.moderation.banInfo(bans[0].key, function (err, info) {
            t.error(err)
            t.deepEqual(info.content, {
              key: key1,
              reason: 'spammer'
            })
            t.ok(info.timestamp)
          })

This required an upstream change in materialized-group-auth in 1.2.0.

+94 -8

3 comments

4 changed files

substack

pr closed time in 3 months

pull request commentcabal-club/cabal-core

moderation.banInfo

handled by cabal.getMessage() in #83

substack

comment created time in 3 months

push eventcabal-club/cabal-core

substack

commit sha d64a24d4214e31f11288e416c45a998cfccf4a26

moderation.list() with additional cross-channel test and some fixes

view details

push time in 3 months

created tagsubstack/materialized-group-auth

tag2.1.0

materialize a group authentication database view from a log of operations

created time in 3 months

push eventsubstack/materialized-group-auth

substack

commit sha 6cb58408338922fe8f850b36dc6543dd4d4f6e6d

list()

view details

substack

commit sha 7754d2ee9c2bb0d2ab5b8bc30a21797d81e1420f

2.1.0

view details

push time in 3 months

created tagsubstack/materialized-group-auth

tag2.0.1

materialize a group authentication database view from a log of operations

created time in 3 months

push eventsubstack/materialized-group-auth

substack

commit sha d4d81b3e911ffe55b3ce40df940a2271056574a3

2.0.1

view details

push time in 3 months

push eventsubstack/materialized-group-auth

substack

commit sha b46a3f7e89dcd0ed5f02a20bba3e9b5be8f1ea42

role => flags

view details

substack

commit sha 0eee5046b744f6fa57a7a37df9a8ee00a7cb8ce4

2.0.0

view details

substack

commit sha b56812b28ced287a63fb705f4d6094b57ce3cff9

remove conditional

view details

push time in 3 months

PR opened cabal-club/cabal-core

moderation based on flags

This is an alternative to #80 using the flag approach that landed in materialized-group-auth 2.0.0. This approach streamlines much of the handling and supports blocks, hides, mutes, as well as other flags that might be required depending on the user feedback for moderation.

Instead of dedicated methods for block()/unblock() etc, you can add and remove arbitrary flags with setFlags()/addFlags()/removeFlags().

+335 -173

0 comment

5 changed files

pr created time in 3 months

create barnchcabal-club/cabal-core

branch : mod-flags

created branch time in 3 months

created tagsubstack/materialized-group-auth

tag2.0.0

materialize a group authentication database view from a log of operations

created time in 3 months

push eventsubstack/materialized-group-auth

substack

commit sha 22b7cc5e12f086f2203f9c4eb51120ce7a9a8e7f

skip and update events

view details

substack

commit sha 55841916be565be9e232d388a18a79dfe59dab0f

1.3.0

view details

push time in 3 months

created tagsubstack/materialized-group-auth

tag1.3.0

materialize a group authentication database view from a log of operations

created time in 3 months

issue openedcabal-club/commons

moderation mvp

list of tasks for minimal viable moderation feature. edit this post to assign yourself a task or to move tasks around.

tasks for user testing:

  • /hide works in channels + cabal-wide
  • /share share modkey
  • desktop: connect context menu to hide action - nick
  • desktop: connect context menu to set admin/moderator action - nick
  • desktop: logic to hide messages - nick

tasks for feature demo / initial release:

  • figure out good syntaxes for the slash commands (use cblgh's human syntax experiment?)
  • /inspect to see what actions a potential moderator / admin has done
  • desktop: ui to show user mod/admin history - nick
  • add admin/moderator labels in cli
  • add admin/moderator labels in desktop
  • cabal-client
    • query for all mod info on startup - kira
    • listen for "role-changed" events from moderation view + update User objects - kira
  • materialized-group-auth array flags - substack
  • materialized-group-auth - event for capturing "skips" and role changes - substack
  • core/clients?: prevent creating channel called "@"
  • solve hyperswarm connection issues
  • make a video demo for mozilla (just in case) - nick

tasks for after the demo:

  • refactor cabal-core to handle multiple mods & admins in the modkey url (cabal://<key>?mod=aaa&admin=111)
  • command to see applied hides (/modlist?
  • write human friendly documentation for website
  • write low level/white paper-esque documentation on how moderation works
  • make a video demo for the public/website - nick

created time in 3 months

PR closed cabal-club/cabal-client

adds /ban, /unban, /baninfo, /banlist, /role, /mod, and /admin commands

depends on https://github.com/cabal-club/cabal-core/pull/80

I've tested some scenarios on a local cabal (but not all). I was able to add an admin, see their ban (with /banlist) and see the ban disappear with /unban.

+181 -3

4 comments

3 changed files

substack

pr closed time in 3 months

more