i also hate fedi handles. you can't do initial @ without being centralized. that was twitter's whole deal. it was a flex for them that they monopolized having an identity online. we don't actually need to look different than email
Post
literally the format everyone understands to specify username hosted at domain
"what if someone tries to email it thinking it's an email" right so they remember your handle with domain flawlessly but don't remember whether it was an email address or fedi account. sherlock holmes please give me a clue
@hipsterelectron we could integrate email into it! your fedi handle is also a valid email address
i do think it's really cute how mastodon decided to actually break twitter/every website's URL conventions and put the @ in the URL for the username. "don't break the web"
also if you haven't successfully written an incremental markdown parser used by experts for the past decade+ you are not invited to the table where we discuss the appropriate penance measured in eons of flaming hellfire for adding another @ symbol in a grammatically superfluous location which STILL fails to disambiguate the end of the handle from any suffixed punctuation
am i the only one at this fucking table? damn. maybe i should get a real job censoring LLM output with regex
[language with a vast bevy of suffixed punctuation, spanning millennia of linguistic evolution, and vestigial-to-absent prefix forms]
yeah what i need is a way to unambiguously parse the beginning of a symbol and definitely not the end
anyway the solution to this is fucking obvious it's a third fucking @ symbol at the end
"how will i know when to trigger the username search dropdown without my emotional support load bearing lexical syntax" you should make it trigger upon any keystroke so your users are scared to type anything in your app and just copy/paste from their text editor. it's a best practice
"what if someone parses a fedi handle with an email address parser and it parses incorrectly without erroring":
- yeah it would be crazy if the python wheel METADATA format could parse ambiguously and enable silently injecting arbitrary dependencies right? luckily the pypi security team would never allow anything like that
- why are you scraping email addresses in the first place let's start there
- if you defined a fedi handle as an email address this wouldn't be a fucking problem
"what if someone tried to use a +extension like with email" ok new table time everyone who has typed a +extension email address by hand just in case it worked is invited
i do think it's cute that the single nod to the internet actually consisting of more than one computer (THE HELLISH FUCKING CACHE-CONTROL HEADER WITH THE SEMANTICS FROM HELL) is only mentioned in passing in the w3c spec https://www.w3.org/TR/activitypub/#server-to-server-interactions
HTTP caching mechanisms [RFC7234] SHOULD be respected when appropriate, both when receiving responses from other servers as well as sending responses to other servers.
"we acknowledge that there is already a TTL infrastructure we could use for e.g. how to enforce a Delete request, but instead we are going to write a sentence stating that enforcement of a Delete is Heresy."
you know when you've found the True Spec when it stops saying MUST and SHOULD and starts talking like a police negotiator
the server MUST target and deliver to the values of to, cc, and/or audience if and only if all of the following are true:
say the line bart
The server MAY filter its delivery targets according to implementation-specific rules (for example, spam filtering).
ok that's actually the worst "if and only if" i've ever read in my entire life. disproved gödel by containing an incorrect assertion of its internal consistency
this is such a confusing and strange way to justify a piece of functionality https://www.w3.org/TR/activitypub/#shared-inbox-delivery
For servers hosting many actors, delivery to all followers can result in an overwhelming number of messages sent.
ok after 5 minutes i realized this just means they don't have a batch send API and that this is considered a special case
- Some servers would also like to display a list of all messages posted publicly to the "known network".
sounds like surveillance but sure this niche kiosk functionality is worth implementing a completely separate code path for. why not
- Thus ActivityPub provides an optional mechanism for serving these two use cases.
"having >1 users" and "reading everyone's messages" are the two use cases
When an object is being delivered to the originating actor's followers, a server MAY reduce the number of receiving actors delivered to by identifying all followers which share the same sharedInbox who would otherwise be individual recipients and instead deliver objects to said sharedInbox. Thus in this scenario, the remote/receiving server participates in determining targeting and performing delivery to specific inboxes.
a batch API with a negotiation process that segments users into similar buckets. how does this handle scale? presumably with batching. i just guessed that though. maybe it's quantum
@hipsterelectron isnt there other systems that also piggy back on email handles, like I think ActiveDirectory from M$ does so