fair chance that "activitypub" (really activitystreams) as used in fedi software goes the way of "html" as used in web browsers.
-
fair chance that "activitypub" (really activitystreams) as used in fedi software goes the way of "html" as used in web browsers.
anyone trying to do schemas for fedi documents will probably be about as successful as xhtml
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
so i guess the natural followup question is, which WHATWG-like entity is going to arise and fork activitystreams away from the W3C
"meta and mastodon" sounds a lot like "google and mozilla" and i wonder if the numbers are similar too
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
anyway i don't really want this to happen but if it does happen then let the record show that i fuckin' called it.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
honestly from an activitypub standpoint what fedi does is not terribly removed from activitypub, if you take "activitypub" to mean "POST to inbox based on addressing properties". that part generally works. the following protocol is like 80% there. no one actually uses the liking or sharing protocols, they just send the activities.
it's what's *in* those activities that is left completely open. y'know, the entire "rest of the protocol" bits.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
in the same way that an HTTP POST can have arbitrary headers and arbitrary body content, that is.
by which i mean: HTTP is less of an "application protocol" and more of a "transport protocol implemented in the application layer". OSI layers 3-7 virtualized within OSI layer 7.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
the virtual layer 3 "network" of the web is all the web servers as identified by DNS names or IP addresses -- IANA is the network.
the virtual layer 4 "transport" of the web is HTTP messages -- both requests and responses.
the virtual layer 5 "session" has not been built in a standardized way, and neither has virtual layer 6 "presentation", and neither has virtual layer 7 "application".
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
for the most part the "virtual layer 5 session" is ephemeral, and it exists for the lifetime of the HTTP request or response only
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
"virtual layer 6 presentation" is mostly about the data serialization over HTTP -- your xmls and jsons and whatever.
"virtual layer 7 application" is where we want to be. it's where anything useful happens when "on top of HTTP".
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
from this we can envision potential options:
a) go back to the real "layer 3/4" and start over from on top of that. (this is what xmpp does, by building on top of TCP/IP)
b) stop at the real "layer 7" and just directly use HTTP messages. (not too dissimilar from activitypub proper, except instead of AS2 JSON we use the full HTTP message)
b.2) build a new "layer 8" for user agents.
c) virtualize layers 3-7 within the real "layer 7". (basically fedi)
d) expand layer 7 to encompass everything.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
just one big application layer. The App
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
i think somewhere between a and b is what i’m leaning towards, because my thinking is crystallizing re: “virtual osi on top of 7” being mostly bad.
which is to say, in a world where we have:
- TCP/IP/DNS/TLS/HTTP
- TCP/IP/DNS/TLS/XMPP
- TCP/IP/DNS/TLS/SMTP
- etcwhy would we poorly reinvent a virtualized transport layer? why not use what already exists?
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
i think the trap we have fallen into is that we want to use https: identifiers that work in a web browser, because http(s) web browsers are ubiquitous.
but to make https: identifiers the basis of our identity layer is to find ourselves in a situation where we need to reinvent DNS and TLS, but for HTTPS resources.
so we need a “resource name server” (RNS) and a “message layer security” (MLS oh wait that one’s already taken)
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
essentially our TCP/IP/DNS/TLS/HTTP/RNS/MLS stack would let resources send messages to each other, instead of being limited to servers or machines sending messages to each other.
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh the Industry simply decided that HTTPS was the fundamental optimization of the next decades and would replace TCP entirely
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice i hate it here
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh yea
-
alice@gts.void.dogreplied to alice@gts.void.dog last edited by
@trwnh if it wasnt for ruby on rails we'd have collided xmpp and activitystreams by now (false. not true)
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
RNS here being analogous to what the MLS spec calls an “Authentication Service” — basically you give it a name and it looks up records about that resource and provides you with a resource descriptor
WebFinger is a type of RNS, roughly speaking
You could do this over HTTPS-based “Controller Documents” as well, but that limits you to https: identifiers. Having an “RNS resolver” lets you make the transport pluggable. You’re not limited to a single protocol.
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice someone did it i think? libervia?
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
@alice anyway idk if activitystreams is ideal here but i think you could negotiate a profile of it in theory, i do think semantic profiles ought to be negotiable in the same was as cipher suites