b379e7467f
* Allow founders to transfer territories * Log territory transfers in new AuditLog table * Add territory transfer notifications * Use polymorphic AuditEvent table * Add setting for territory transfer notifications * Add push notification * Rename label from user to stacker * More space between cancel and confirm button * Remove AuditEvent table The audit table is not necessary for territory transfers and only adds complexity and unrelated discussion to this PR. Thinking about a future-proof schema for territory transfers and how/what to audit at the same time made my head spin. Some thoughts I had: 1. Maybe using polymorphism for an audit log / audit events is not a good idea Using polymorphism as is currently used in the code base (user wallets) means that every generic event must map to exactly one specialized event. Is this a good requirement/assumption? It already didn't work well for naive auditing of territory transfers since we want events to be indexable by user (no array column) so every event needs to point to a single user but a territory transfer involves multiple users. This made me wonder: Do we even need a table? Maybe the audit log for a user can be implemented using a view? This would also mean no data denormalization. 2. What to audit and how and why? Most actions are already tracked in some way by necessity: zaps, items, mutes, payments, ... In that case: what is the benefit of tracking these things individually in a separate table? Denormalize simply for convenience or performance? Why no view (see previous point)? Use case needs to be more clearly defined before speccing out a schema. * Fix territory transfer notification id conflict * Use include instead of two separate queries * Drop territory transfer setting * Remove trigger usage * Prevent transfers to yourself |
||
|---|---|---|
| .ebextensions | ||
| .github | ||
| .platform | ||
| .vscode | ||
| api | ||
| capture | ||
| components | ||
| copilot | ||
| db | ||
| docs | ||
| fragments | ||
| lib | ||
| pages | ||
| prisma | ||
| public | ||
| scripts | ||
| styles | ||
| svgs | ||
| sw | ||
| worker | ||
| .babelrc | ||
| .env.sample | ||
| .gitignore | ||
| .npmrc | ||
| Dockerfile | ||
| LICENSE | ||
| Procfile | ||
| README.md | ||
| contributors.txt | ||
| docker-compose.yml | ||
| middleware.js | ||
| next.config.js | ||
| package-lock.json | ||
| package.json | ||
README.md
contributing
We pay sats for PRs. Sats will be proportional to the impact of the PR. If there's something you'd like to work on, suggest how much you'd do it for on the issue. If there's something you'd like to work on that isn't already an issue, whether its a bug fix or a new feature, create one.
We aim to have a quick PR turnaround time, but we are sometimes slower than we'd like. In most cases, if your PR is unambiguously good, it shouldn't take us more than 1 week.
If you have a question about contributing start a discussion.
responsible disclosure
If you found a vulnerability, we would greatly appreciate it if you contact us via kk@stacker.news or t.me/k00bideh.
stacker.news
Stacker News is like Hacker News but we pay you Bitcoin. We use Bitcoin and the Lightning Network to provide Sybil resistance and any karma earned is withdrawable as Bitcoin.
wen decentralization
We're experimenting with providing an SN-like service on nostr in Outer Space. It's our overarching goal to align SN with Bitcoin's ethos yet still make a product the average bitcoiner loves to use.
local development
- Install docker-compose and deps if you don't already have it installed
git clone git@github.com:stackernews/stacker.news.git sn && cd sndocker-compose up --build
You should then be able to access the site at localhost:3000 and any changes you make will hot reload. If you want to login locally or use lnd you'll need to modify .env.sample appropriately. More details here and here. If you have trouble please open an issue so I can help and update the README for everyone else.
web push
To enable Web Push locally, you will need to set the VAPID_* env vars. VAPID_MAILTO needs to be an email address using the mailto: scheme. For NEXT_PUBLIC_VAPID_KEY and VAPID_PRIVKEY, you can run npx web-push generate-vapid-keys.
imgproxy
To configure the image proxy, you will need to set the IMGPROXY_ env vars. NEXT_PUBLIC_IMGPROXY_URL needs to point to the image proxy service. IMGPROXY_KEY and IMGPROXY_SALT can be set using openssl rand -hex 64.
stack
The site is written in javascript using Next.js, a React framework. The backend API is provided via GraphQL. The database is PostgreSQL modeled with Prisma. The job queue is also maintained in PostgreSQL. We use lnd for our lightning node. A customized Bootstrap theme is used for styling.
processes
There are two. 1. the web app and 2. the worker, which dequeues jobs sent to it by the web app, e.g. processing images.
wallet transaction safety
To ensure stackers balances are kept sane, all wallet updates are run in serializable transactions at the database level. Because prisma has relatively poor support for transactions all wallet touching code is written in plpgsql stored procedures and can be found in the prisma/migrations folder.
code
The code is linted with standardjs.