MaddyUnderStars / MaddyUnderStars/shoot

some of my notes from months ago

Open
#4 6 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.