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
Replies:
31
Boosts:
8
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
Receiving a Create activity in an inbox has surprisingly few side effects;
you can't post this in a spec. that's not real
the activity should appear in the actor's inbox
ok i searched "appear" and this is a gold mine. new tangent:
APPEAR [1/6]
Servers SHOULD validate the content they receive to avoid content spoofing attacks.
SHOULD? a little spoofing is ok? as a treat?
(A server should do something at least as robust as checking that the object appears as received at its origin,
"at least as robust as [thing we never define, explain, nor mention ever again]"
but mechanisms such as checking signatures would be better if available).
who the hell is the president i'd like to have a word with him
No particular mechanism for verification is authoritatively specified by this document,
we would NEVER misuse our authority to SPECIFY a DOCUMENT
but please see Security Considerations for some suggestions and good practices.
not best. good
If it appears that the user neglected to add a scheme for a URI that would otherwise be considered valid, such as example.org/alice/, clients MAY attempt to provide a default scheme, preferably https.
unaccountable RCE vector with no concept of validity that can be injected anywhere in the chain. great
The server MUST then add this new Activity to the outbox collection.
MUST is how the IETF tells you to fuck off
Depending on the type of Activity, servers may then be required to carry out further side effects.
fork may be required to carry out kitchen-based operations
(However, there is no guarantee that time the Activity may appear in the outbox.
MUST!!!!! MUST!!!!!!! MUST!!!!!!!
(to be clear this is nonsensical, but not a typo. some mistakes cover up atrocities)
The Activity might appear after a delay or disappear at any period).
activitypub is the first protocol to specify NOP as a complete conforming implementation
These are described per individual Activity below.
double trigger warning for description of behavior since many implementors like gargron are deathly afraid of implementing behaviors
actually that was three appears at once above. and we conclude with the one that started it all:
Receiving a Create activity in an inbox has surprisingly few side effects;
so that was an incorrect tw first of all
the activity should appear in the actor's inbox
brain destroying prose. active nerve poison
and it is likely that the server will want to locally store a representation of this activity and its accompanying object.
"locally store a representation" ah! yes! a representation! the thing JSON-LD cannot be used for because JSON-LD is a sick mr. beast youtube game and not a data format
However, this mostly happens in general with processing activities delivered to an inbox anyway.
i know this wasn't LLM generated because LLMs are not self-aware enough to identify their own completely circuitous, misleading, and outright redundant tautology, in the body of a published standards document
if your federated (server-to-server) protocol has an overview which:
- says repeatedly "users are actors" (repeatedly contradicted below)
- says json-ld is "plain old simple json"
- says "technically client to server and server-server are different", then provides this image that it tells you is misleading and wrong:
don't worry, JSON-LD documents
no way to improve upon this text
(If you're going to add extensions, that's the point at which JSON-LD really helps you out).
crazy thing to say in a specification document. this is not a spec. why was this added to w3c at all??? why is this not an IETF standard?
not a rhetorical q this time. now i'm gonna see if they answer that anywhere
how is activitystreams worse https://www.w3.org/TR/activitystreams-vocabulary/#inverse
5.5 Inverse Activities and "Undo"
foreboding
This section is non-normative.
THAT IS THE ELDEN RING BOSS BATTLE SIGN YOU ARE SECONDS AWAY FROM GETTING SMACKED BY A TREE
It is important to note that these types of activities are semantically distinct from one another and have no direct relationship on the other. That is, for example, if an actor "likes" a note at one point in time then later "dislikes" it, the "dislike" activity does not "undo" or negate out the prior "like".
that's. thanks
The Undo activity type is defined to provide the specific ability to undo or cancel out a prior activity.
"mutually exclusive" => big words, shut up nerd, combinatorial verbs are more pythonic, abstracting too early, L + ratio
"undo" => everything can be undone. figure out the operational semantics yourself nerd. state monad burrito
The appropriate interpretation for the following, then, is that Sally liked John's note at one point but has explicitly redacted that like later on.
type of guy who uses "explicitly redacted" as a linguistic intensifier
@hipsterelectron isnt there other systems that also piggy back on email handles, like I think ActiveDirectory from M$ does so
