MaddyUnderStars / MaddyUnderStars/shoot
some of my notes from months ago
- Dominant language
- TypeScript
- Stars
- 61
- Forks
- 5
- Avg merge
- 3d 10h
- Merged PRs (30d)
- 1
Description
this is my `notes.md` file from months ago when I was working more actively. it might be useful to someone else
federation:
TODO: look into the fep for Group federation. if I can implement it, it would be better for interop
currently when a remote server wants to send a message, they Create\ at a channel
and then that channel Announces that
this means that every message has to go through the channel owner
pros:
- the owning instance can more effectively moderate and control which messages federate more widely
- easier logic
- would allow for better information hiding of things like automod rules if those ever exist, since the remote instances wouldn't need a copy
cons:
- for every message, the owning instance must send a copy to every other instance
alternatively, when a message is sent by a remote, it could be the one to distribute the message to each member instance
pros:
- less strain on the owning instance, each member instance is responsibile for distributing their usage
cons:
- harder to control which messages get federated
- in extension to that, harder to do instance blocking
- harder to do automod
instance blocking:
when an instance is blocked by a guild owner instance, the remote instance loses access to that entire guild
however, if a remote instance A blocks another remote instance B, messages sent from A to the guild will be received by everyone except B
this is same problem that mastodon/etc already have
this may be fine, since in a chat app, if you block someone, you'll still receive all the chatter around that anyway
so this is pretty expected behaviour from a users POV
tools:
- users should be able to block users or whole instances
- admins should be able to block users or whole instances
- users should be able to set guilds/channels as restricted to specific instances, or denylist other instances
- - perhaps even users
- users should be allowed to allow, reject, or approve incoming DMs
- - DMs awaiting approval should not be visible at all times i.e. behind some other screen
- - there should be a way to remove all or accept all awaiting approval
- - you should be able to block users/instances from this screen
- guilds/channels should also have a request to join feature i.e. you use the invite code and it is not automatically accepted but is added to a approval list
- there should be automated spam filters
- - check out https://github.com/MarcT0K/Fediverse-Spam-Filtering
- - - automated training could be done i.e. through users reporting content as spam. this could be manually reviewed by a moderator
- - also the iftas csam filtering service
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading notes.md and compare its federation, blocking, moderation, and approval ideas with the repository's current implementation. No entry point, test, or concrete change is identified, so the expected behavior and definition of done would need to be agreed before work begins.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- express, nodejs, typescript
- Domain
- backend, distributed-systems, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100