wildcards for instance allowlist and blocklist domains
how does this work atm? lists of fqdns?
I believe it's this bit of code:
if local_site_data
.blocked_instances
.iter()
.any(|i| domain.to_lowercase().eq(&i.domain.to_lowercase()))
{
Err(LemmyErrorType::DomainBlocked(domain.clone()))?
}
which gets blocked_instances
filled in from the database and domain
from the connecting instance. so it's just a case insensitive string match of everything in the block list against the exact hostname given by the connecting instance as given by ActivityPub -- presumably that layer takes care of ensuring the provided hostname is actually the instance's domain name. so in short I have to do a bunch of stupid shit to block an instance thoroughly, and good luck if I want to block a domain and all of its subdomains
on the all local comments page, a "next" button that works
cherrypick the commit that makes authorized_fetch with Mastodon instances function, add a toggle for this setting to the UI, and enable it by default
oh I keep forgetting to log this one: move the i_love_jesus
microdependency into a backend workspace crate (to prevent a potential security issue) and rename it (just cause)
maybe a better markdown implementation? the current one has a lot of oddities I've never seen in a markdown editor before
that'll devalue my Lemmy Ate My Formatting ~~property~~ t-shirt! I protest!*
(* I most definitely do not protest)
they rolled their own right? there must be a pile of rust markdown implementations
I'm fairly certain they did based on how it works -- if that's the case, I consider it fairly low hanging fruit to swap to something more sensible. this'll break our compatibility with other instances in a minor way if we do it since we won't be rendering posts in the same broken way, but I feel like the risk is fairly minor. I'll check on this and post an update once I get started on the rebrand for the frontend
I was percolating on this. And here’s a maybe-nasty workaround that may even be usable in federated manner (I have no idea if this is even viable, need to learn some AP)
Internally store posts in raw and some kind of decorated-raw format, where the “decorator” is essentially some frontmatter that specifies rendering/renderer properties. Think <!-- renderbits: […..] -->\n\npostgoeshere
Upside of this approach is that if it is federable (and again, dunno, will need to check still 😅), it can allow each instance to self-handle as needed, along with providing own fallbacks and stylemaps
so the frontend uses markdown-it which is fairly popular; I think the problems with it are the settings they configured for markdown-it
's parser, and the almost 800 line MarkdownTextArea
making interacting with the damn thing so clumsy. we can probably get a pretty good improvement out of changing to a saner markdown-it
configuration and swapping the MarkdownTextArea
component for something well-supported from NPM
FreeAssembly
this is FreeAssembly, a non-toxic design, programming, and art collective. post your share-alike (CC SA, GPL, BSD, or similar) projects here! collaboration is welcome, and mutual education is too.
in brief, this community is the awful.systems answer to Hacker News. read this article for a solid summary of why having a less toxic collaborative community is important from a technical standpoint in addition to a social one.
some posting guidelines apply in addition to the typical awful.systems stuff:
- all types of passion projects and contributions are welcome, including and especially those that aren't programming or engineering in nature
- this is an explicitly noncommercial, share-alike space
- don't force yourself to do work you don't enjoy, or demand it of others
(logo credit, with modifications by @dgerard@awful.systems)