sahil

boom revamp

now shows author (with pfp) - removed tags for now, since they’re all added after the fact. might come back and completely rework it later so it’ll be able to edit more stuff.

also added .env.example and manifest.yml (had to start a new dev bot from scratch, so probably will help when I come back to this a few months down the line :pf:)

that’s about it!

WE ARE REWRITING TS 🔥

First - implemented protection through send permissions. This is vastly more effective than kicking them (race condition) and also looks cooler! Downside: it’s a little more to manage, because there’s no easy way to just say “gib permission” and “no gib permission” - you have to set the entirety of the permissions (which are stored in such a weird way lol). There’s so many new things unlocked here, so I’ll detail those later as well.

After a bit of work on the send permissions thing, I made a whitelist. Simple. Whitelist a user from IDV blocks. Or perhaps whitelist a bunch of people. Simple.

There was one big problem though. The means by which I accomplished this essentially meant scattering logic in a ton of different places. I’d have logic in leave/join handlers, and honestly, the entire codebase was a mess.

I took the decision to instead rework the entire codebase, with a new strategy. I’d keep all user info stored in the SQLite database, and all commands would interface with that database. Then, that database would be synced with Slack. This way, the logic ends up being separated out.

This was enough of a shift that warranted the creation of a new repo. New deployment issues, new failures, a bunch of nonsense with token rotation and app creation, and there we go!

IDV protection? Hell yeah! #idv-only only lets IDVed members join.

Whitelists are now a thing, and /blam whitelist channel keeps all members in the channel allowed for the future.

/blam help shows all available commands.

Lots of perf improvements

/idv test basically runs through the users and finds out how many of them would be affected by a /blam idv - it does need performance improvements soon :pf:

That’s about it for now! Lots of edge cases are hanging around that need to be patched up.

Accidentally worked on this file in flavortown-watcher 😔

Wrote a few helpers to check if someone’s IDV verified.

Thanks Amber for the idea! #arcade-hcb-tracker was pretty cool, but text is bland. So I used Slack’s Block Kit to make a few blocks, and show it in red or green.

Then, I began displaying all tags on the bottom of the card.

I noticed the link on the transaction from the Arcade HCB tracker was probably to an internal log. I copied it :D

I don’t have any ideas for what to add/change, so for now this will be the first and last devlog. If you have any ideas for what to add, or even for an alternate UI for this, I’m all ears!

Whoah, first devlog! Lots of progress so far:

1. Tried to use libsql, failed miserably -> chose to use the tried and trusted sqlite
2. Figured out how to auth and use XOXP tokens to kick users
   2.5. Added a whole lot of cruft in the process :P
3. Individual users can now be prevented from joining (need to figure out how to add custom filters)
4. Made the bot and the user both readd each other in case of removal by a non channel manager

But then, I ran into a problem - occasionally, XOXP tokens don’t work to kick. And users added to channels don’t seem to be able to kick immediately. And even more worryingly, even with channel manager given to the kicking user, it fails. I believe it’s because the XOXP has to be refreshed (manually?!) each time it’s added.

Yeah, that’s not going to work. I made a little hack that uses XOXC and XOXD tokens instead to kick, and it works!

I skipped over a lot of detail in how many times I failed, but yeah that’s about it!

Also - I’m really kind of happy with the _env implementation I landed on. I wrap all my getenv calls in a custom function which validates the vars.