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
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
factor browser-pack bundles into common shared bundles
launch a web worker that can require() in the browser with browserify
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
commit sha 016fb49f2428a70a5c3d96f723fa0680ac8a2ff5
forward and format errors
push time in 3 days
push eventpeermaps/eyros
commit sha 77519ef208d692c2e67f87eda45f5390ea5f9c70
wasm storage compiles
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.
comment created time in 5 days
push eventpeermaps/eyros
commit sha 0913714bce8928ceacffd52f3ff7406e1cae8b38
wasm browser storage stub
push time in 21 days
issue commentpeermaps/eyros
The async branch passes all tests.
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.
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
comment created time in 24 days
push eventpeermaps/eyros
commit sha 86e8bc96fd695938a29878f8c7c657fadf5999ef
updated tests and docs for async
push time in 24 days
push eventpeermaps/eyros
commit sha 2a7ed0907b65773e92cf7b29e768660f0cad320d
indirect Storage trait and it compiles again finally
push time in 25 days
push eventsubstack/parse-bga-mesh
commit sha 08603d81dc6410be4b15bce2fe4063ef7578f95c
also ignore glb and gltf files
commit sha 92d1ef49e442e2266dfafbd8873bc8855d0730ea
2.0.2
push time in 25 days
PR merged peermaps/eyros
This fixes some of the errors on the async branch. Thanks!
pr closed time in a month
push eventpeermaps/eyros
commit sha ad2a3fe9551cc719123ceb39a4908414997bfbd0
Unpin futures
commit sha d03c7cb01b4f69f6a9858dceed1d5caacfc6ed02
with box errors
commit sha f774290c5ec1e7cde687be9101dacc129169ace2
convert to boxed std error type
push time in a month
pull request commentcabal-club/cabal-client
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.
comment created time in a month
startedgarbados/pouchdb-hypercore
started time in a month
PR opened cabal-club/cabal-client
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
pr created time in a month
push eventcabal-club/cabal-core
commit sha b855c60e980152d6b2d3ad834f3eacb332f7fd9a
removeConnection() method and save the info instance from the swarm
push time in a month
push eventcabal-club/cabal-core
commit sha b4d51d8b8e0a455dbb1881ea363030392b2588cb
verify() should receive a hex string and fix bug not adding connection correctly
push time in a month
PR opened cabal-club/cabal-core
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.
pr created time in a month
push eventcabal-club/cabal-core
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 ```
commit sha aa5dac5b2b339cc588dee751bf89cb9632528d12
update readme to indicate flags used by cabal-core
commit sha 2f41eb575ddbc1644dd113f42c361101bcca9431
Merge pull request #94 from garbados/patch-1 Document possible flags for `listByFlag`
commit sha 309ea5c2ef9ca6dbf31c5ce178d00847061677c2
Merge branch 'master' of github.com:cabal-club/cabal-core into swarm-auth-hook
push time in a month
PR opened kappa-db/multifeed
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.
pr created time in a month
created tagsubstack/hypercore-authenticate-session-extension
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
commit sha 2391e9c50ecd2b1baa252f2991bc5210a8bc2733
more helpful error message if handshakeHash not found
commit sha 1430f0a2f11ff9e714a670b5cc2c0e27636c7271
1.0.1
push time in a month
push eventsubstack/hypercore-sign-noise-key-extension
commit sha 9e7745c8a333e173be1bbd189f2995a5ada9360b
rename project and use handshake hashes
push time in a month
PR opened mafintosh/simple-hypercore-protocol
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.
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
created branch time in a month
created tagsubstack/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
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
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.
comment created time in a month
PR merged cabal-club/cabal-core
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()
pr closed time in a month
push eventcabal-club/cabal-core
commit sha 9ab9c74c8a219f1415ba75e9443bfdde0532272c
duplexify must be in object mode for mod streams
commit sha e3e35072c02c30bb90538927bd29b5ee0837ef78
13.0.2
push time in a month
push eventpeermaps/eyros
commit sha eef3cab1fd266e0336152cb88cf1dbdf333997b6
unfold impl
push time in 2 months
push eventpeermaps/eyros
commit sha 09edf53c21ca8e51992d670c55c56e94e4e1de82
messed up this commit
commit sha 50f737b118af743b5692893f6200c333f2b5b596
current state
commit sha 434c05f4eb795e48f1f12ee0be520eef09b25c4c
fixed commit
push time in 2 months
issue commentcabal-club/commons
We can use some copy and art assets from the zine https://substack.net/zine/cabal.html
comment created time in 2 months
issue commentcabal-club/commons
mozilla mvp cabal demo
outline
- brief intro about cabal and the subjective moderation system
- as user A: create a new cabal
- as user A: send a link to friends with user A as the mod
- as user B (not presenting): post a spammy message
- as user A: ban user B for being a spammer
- as user C (not presenting): say that cats are good
- as user A: ban user C for saying that cats are good
- as user D: undo the previous ban from user A
- as user E: set mod key to user D. show how user C reappears
- as user E: add user C as a moderator
- discuss findings from user research and cblgh thesis
- 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
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.
comment created time in 2 months
issue commentRangerMauve/hyper-presence
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)
}
comment created time in 2 months
issue commentRangerMauve/hyper-presence
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.
comment created time in 2 months
push eventpeermaps/eyros
commit sha 105a549ae3b916dc8344b922205b1e1f9ffde40c
fixed stream using unfold from the futures crate
commit sha ce1e5708076ff31abeab7914a6e3435f6485c322
main lib compiles async finally
push time in 2 months
PR closed substack/desert
pr closed time in 2 months
PR opened cabal-club/cabal-cli
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:
After:
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.
pr created time in 2 months
push eventcabal-club/cabal-core
commit sha e233483dd36957a77699a4ed40af1c3526553e7b
fix skipped failing tests
push time in 2 months
PR merged cabal-club/cabal-core
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.
pr closed time in 2 months
push eventcabal-club/cabal-core
commit sha 3861da278c6d73081749003ef5c6e41fa16c5e89
listModerationBy function and secondary index
commit sha eec03f7d92006f676c3b8295dbadb23bca3bd95c
Merge branch 'master' into list-moderation-by
commit sha 1e0a8a8d8a8a51527d627d98130c7ae543223eaa
document listModerationBy
commit sha 97b91c84887cf121d4ca30ca2f15016b17f3b2b0
Merge branch 'master' of github.com:cabal-club/cabal-core
commit sha a96c9599cf19c7718be5fe0cd71eb7d383bd7037
11.2.0
push time in 2 months
pull request commentcabal-club/cabal-client
The /inspect implementation depends on cabal-core/#87.
comment created time in 2 months
push eventcabal-club/cabal-client
commit sha 75a2fb2f99dd127f6ac312f29b26da29ef87b670
inspect command
push time in 2 months
PR opened cabal-club/cabal-core
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.
pr created time in 2 months
push eventcabal-club/cabal-core
commit sha 1e0a8a8d8a8a51527d627d98130c7ae543223eaa
document listModerationBy
push time in 2 months
PR merged cabal-club/cabal-core
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 :^)
pr closed time in 2 months
push eventcabal-club/cabal-core
commit sha 14167e31122c9cd88839f0a63d6fbafdbb533de1
use admin for admins, instead of mod
commit sha 3cda999bf9b139dc8dd916018eb9f035dc750550
test for setting multiple admins and mods in the cabal addr
commit sha 8e27c3786d181c98136078f4d85eeb23d04df2eb
use admin for admins, instead of mod
commit sha b4d6463efd6a71426364781b22762f719b2738ed
Merge branch 'use-admin-not-mod' of github.com:cabal-club/cabal-core into use-admin-not-mod
commit sha 04cf3353a54c9bf0819d758b0556f895e8acf79c
fixes for admin and mod keys in cabal urls
commit sha 2e60cffae3169ba7bf81db8aa18c82e40bb2089d
fix merge issue
commit sha 779a500c5d2f3b6fb4e75c5a98af96389cfe9a8e
11.1.0
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
comment created time in 2 months
push eventcabal-club/cabal-core
commit sha 3cda999bf9b139dc8dd916018eb9f035dc750550
test for setting multiple admins and mods in the cabal addr
commit sha 04cf3353a54c9bf0819d758b0556f895e8acf79c
fixes for admin and mod keys in cabal urls
commit sha 2e60cffae3169ba7bf81db8aa18c82e40bb2089d
fix merge issue
push time in 2 months
push eventpeermaps/eyros
commit sha dd3b7b713f4036aee1eb26381228d9065669b153
still not compiling
push time in 2 months
push eventcabal-club/cabal-core
commit sha 4c17ace1105dab59d07db46fb1dd8d6bc849228b
failing test case for adding then removing a block
commit sha a98ac48545c44d19b347784de09132de19b71a24
fix remove flag for moderation
commit sha e75bd67db9938848d1c8d6064181c7820c9c208c
11.0.1
push time in 3 months
push eventcabal-club/cabal-client
commit sha d7f72cb7a467121f466f0b2308e88c8c838f1d67
use cabal-core 11.0.0
push time in 3 months
PR merged cabal-club/cabal-core
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().
pr closed time in 3 months
PR merged cabal-club/cabal-core
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
pr closed time in 3 months
push eventcabal-club/cabal-core
commit sha a699e32026abe18855f884eedfc39b7ce05078a5
moderation based on flags
commit sha d64a24d4214e31f11288e416c45a998cfccf4a26
moderation.list() with additional cross-channel test and some fixes
commit sha 4dea82e46155a769f2f2d7270f01d8223b9bd2eb
Merge branch 'master' of github.com:cabal-club/cabal-core into mod-flags
commit sha 541d2e126bd9d20adebc6a3a7c8d6a78359d552f
pass through additional fields when setting flags
commit sha f02352a21cd1b18d596698cfee4f5ae37a7204e2
add support for mod & admin keys in cabal key uri
commit sha 7118a5cc5b057767fe48da207e19860775b9f33e
Merge branch 'mod-key-v2' of github.com:cabal-club/cabal-core into mod-key
commit sha ae7ea34482ad21e42113d722cb4b39f41c50c343
use modkey from url
commit sha 330aff8ce6c101ed76c5985dba828c9631633912
11.0.0
push time in 3 months
pull request commentcabal-club/cabal-client
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
comment created time in 3 months
push eventcabal-club/cabal-client
commit sha d020cd0c0693aeae8851d947c781524d28f7be3e
update commands to match commands gist. un-commands not completely working yet, others TODO'd
push time in 3 months
push eventcabal-club/cabal-core
commit sha aac5ed4e37a3da6d3bfe837a41c259e594644e9a
remove package-lock.json
commit sha 736cd7319312a41d2d154d7199f3e27614b3b99c
Merge pull request #84 from cabal-club/rm-package-lock remove package-lock.json
commit sha 4dea82e46155a769f2f2d7270f01d8223b9bd2eb
Merge branch 'master' of github.com:cabal-club/cabal-core into mod-flags
commit sha 541d2e126bd9d20adebc6a3a7c8d6a78359d552f
pass through additional fields when setting flags
push time in 3 months
push eventcabal-club/cabal-client
commit sha 01ba1c11ee9c57ff33fef8b87b7ccb88bd406487
cannot join @, trim leading #s, /part alias
push time in 3 months
push eventcabal-club/cabal-client
commit sha 49704ecdb23ed65206c20d15b8522c7cc8a1a775
updated to use flag-based cabal-core moderation patch #83
push time in 3 months
PR opened cabal-club/cabal-cli
It's possible for state.collision to be checked before an update comes in that initializes the value, which can crash the program.
pr created time in 3 months
PR opened cabal-club/cabal-core
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.
pr created time in 3 months
PR closed cabal-club/cabal-core
This patch builds on #78 and #77 and adds:
- unban
- addMod
- removeMod
- addAdmin
- removeAdmin
- moderation.getRole
- moderation.modInfo
- moderation.listMods
- moderation.listAdmins
pr closed time in 3 months
pull request commentcabal-club/cabal-core
closing in favor of #83
comment created time in 3 months
PR closed cabal-club/cabal-core
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.
pr closed time in 3 months
pull request commentcabal-club/cabal-core
handled by cabal.getMessage() in #83
comment created time in 3 months
push eventcabal-club/cabal-core
commit sha d64a24d4214e31f11288e416c45a998cfccf4a26
moderation.list() with additional cross-channel test and some fixes
push time in 3 months
created tagsubstack/materialized-group-auth
materialize a group authentication database view from a log of operations
created time in 3 months
push eventsubstack/materialized-group-auth
commit sha 6cb58408338922fe8f850b36dc6543dd4d4f6e6d
list()
commit sha 7754d2ee9c2bb0d2ab5b8bc30a21797d81e1420f
2.1.0
push time in 3 months
created tagsubstack/materialized-group-auth
materialize a group authentication database view from a log of operations
created time in 3 months
push eventsubstack/materialized-group-auth
commit sha d4d81b3e911ffe55b3ce40df940a2271056574a3
2.0.1
push time in 3 months
push eventsubstack/materialized-group-auth
commit sha b46a3f7e89dcd0ed5f02a20bba3e9b5be8f1ea42
role => flags
commit sha 0eee5046b744f6fa57a7a37df9a8ee00a7cb8ce4
2.0.0
commit sha b56812b28ced287a63fb705f4d6094b57ce3cff9
remove conditional
push time in 3 months
PR opened cabal-club/cabal-core
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().
pr created time in 3 months
created tagsubstack/materialized-group-auth
materialize a group authentication database view from a log of operations
created time in 3 months
push eventsubstack/materialized-group-auth
commit sha 22b7cc5e12f086f2203f9c4eb51120ce7a9a8e7f
skip and update events
commit sha 55841916be565be9e232d388a18a79dfe59dab0f
1.3.0
push time in 3 months
created tagsubstack/materialized-group-auth
materialize a group authentication database view from a log of operations
created time in 3 months
issue openedcabal-club/commons
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:
/hideworks in channels + cabal-wide/shareshare 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?)
/inspectto 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
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.
pr closed time in 3 months