6 ms·

This RFC is really indicative of what I hate about certain standards. This is all very abstract. No user agent will use this in the same way. You'll end up wri

This RFC is really indicative of what I hate about certain standards. This is all very abstract. No user agent will use this in the same way. You'll end up writing code per application anyway. All this is is a convention that people will interpret a bunch into. This is not going to be interoperable. The epitome of this is ActivityPub.

userbinator 7y ago
It's not surprising, almost anyone can publish an RFC by doing the appropriate bureaucracy so there are plenty of RFCs which no one really cares about.
derefr 7y ago
What does it matter what the UA does with the information? The point is that the information is supplied; the UA can provide whatever benefit from it that the user wants from it. For example, I was just thinking that forum software could have their backends scrape image links you attempt to embed; and, if they find that the link has a sunset policy (e.g. it was from an anonymous image upload service that expires posts after a week), then they could rehost the image instead of hotlinking to it. (Or, cache the image for now, and then rewrite the link from a hotlink to a cached link when the deadline hits.) That’s not something you would standardize behaviour on. But, once you have servers providing the information—not to a particular client, but just spewing it out as an objective fact out into the world—clients can do all sorts of things.
- jimktrains2 7y ago
  Or HTTP-based APIs could check for it and write out log entries or send out alerts to notify ops or the devs that they'll need to investigate further as to how this affects them.
- sascha_sl 7y ago
  Standardisation does nothing for this. The software could've always just used an X-Sunset header or just another field in their dto. My point was that there will never be a client that will blindly read that value and understand what to do with it. Which is why the only difference to "X-Sunset" is that there's an RFC with suggestions on how it could potentially be meant there, along with a syntax restriction. ActivityPub is the epitome of this because they supply a lot of vocabulary and syntax variation to express them (including very complex ways to normalise that syntax, JSON-LD is not fun to parse) but doesn't actually made the implementation commit to anything. It's setting up a bunch of arbitrary rules for nothing. Every single AP implementation still orients itself on compatibility with Mastodon.
  - jayd16 7y ago
    >Standardisation does nothing for this Sure it does. If the information is standardized then the community as a whole can innovate around it. Browser plugins and the like can be made that make use of the information, etc.
deleted 7y ago
[deleted]
cjslep 7y ago
ActivityPub is more about living in a small part of a very big linked data graph and letting very different kinds of apps federate amongst themselves disjointly, encouraging more diverse apps that actually can interoperate with these two disjoint groups and provide niche value without the networks being a walled garden. Very different than an HTTP header.
- sascha_sl 7y ago
  Hey CJ. I don't think that graph will ever be readable without vendor-specific hacks applied for every piece of software participating. AS will meet the same fate as XMPP. Some very core features might work, but the diversity in user agents and servers and their quirky implementations will ultimately be to its detriment. Maybe that's leftover pessimism from the time I participated in the XMPP WG. I'd love to be wrong. I have a lot of respect for implementing AS in Go. I tried and didn't even finish my relay implementation. It was just too counter to the Go core competency and mindset. Or I'm just not a fan of wrangling interface{}s around.
  - cjslep 7y ago
    Hey! I totally understand the pessimism. I am untainted by XMPP for better or worse. I started typing out a reply on my phone but I think I need to sit with a keyboard and just make a blog post on it -- I hope you don't mind a wait. I hope I'll do a fair job characterizing the problems you identity and give them my alternate outlook.
- thejohnconway 7y ago
  ActivityPub is too complicated and loosey-goosey. There are a couple of dozen partial implementations out there, but most of them don't federate properly or at all (which I thought was the entire point of the spec!). Ideally such a standard should be really easy to implement, so we get true diversity, and democratisation, but implementing ActivityPub is a nightmare. Of course it doesn't help that the test suite has been down for months. https://test.activitypub.rocks https://test.activitypub.rocks
  - 7y ago
WorldMaker 7y ago
In this particular case, this RFC isn't Standards Track, it is merely Informative, presumably partly because it isn't normative (it's not about behavior but about conventions/hints).
- lightgreen 7y ago
  This RFC reserves an http header name. Is is not just informative.
  - WorldMaker 7y ago
    Many capital-I Informative RFCs reserve things like HTTP Header Names. Some of the easiest examples are April Fools RFCs that reserve all kinds of things, and while some people do like to use HTTP 418 I'm a Teapot (https://http.cat/418 https://http.cat/418), that's not a capital-S Standard. The IETF has workflows for Informative things versus Standard things. It's still useful to "reserve" things in Informative RFCs in case the RFC later moves to the Standards Track. Or also as some of the April Fools RFCs seem to indicate the internet takes its jokes pretty seriously and you never know when an Informative thing maybe adopted just because it was interesting to some developer for some project.

userbinator 7y ago

It's not surprising, almost anyone can publish an RFC by doing the appropriate bureaucracy so there are plenty of RFCs which no one really cares about.

derefr 7y ago

What does it matter what the UA does with the information? The point is that the information is supplied; the UA can provide whatever benefit from it that the user wants from it. For example, I was just thinking that forum software could have their backends scrape image links you attempt to embed; and, if they find that the link has a sunset policy (e.g. it was from an anonymous image upload service that expires posts after a week), then they could rehost the image instead of hotlinking to it. (Or, cache the image for now, and then rewrite the link from a hotlink to a cached link when the deadline hits.) That’s not something you would standardize behaviour on. But, once you have servers providing the information—not to a particular client, but just spewing it out as an objective fact out into the world—clients can do all sorts of things.

jimktrains2 7y ago
Or HTTP-based APIs could check for it and write out log entries or send out alerts to notify ops or the devs that they'll need to investigate further as to how this affects them.
sascha_sl 7y ago
Standardisation does nothing for this. The software could've always just used an X-Sunset header or just another field in their dto. My point was that there will never be a client that will blindly read that value and understand what to do with it. Which is why the only difference to "X-Sunset" is that there's an RFC with suggestions on how it could potentially be meant there, along with a syntax restriction. ActivityPub is the epitome of this because they supply a lot of vocabulary and syntax variation to express them (including very complex ways to normalise that syntax, JSON-LD is not fun to parse) but doesn't actually made the implementation commit to anything. It's setting up a bunch of arbitrary rules for nothing. Every single AP implementation still orients itself on compatibility with Mastodon.
- jayd16 7y ago
  >Standardisation does nothing for this Sure it does. If the information is standardized then the community as a whole can innovate around it. Browser plugins and the like can be made that make use of the information, etc.

deleted 7y ago

[deleted]

cjslep 7y ago

ActivityPub is more about living in a small part of a very big linked data graph and letting very different kinds of apps federate amongst themselves disjointly, encouraging more diverse apps that actually can interoperate with these two disjoint groups and provide niche value without the networks being a walled garden. Very different than an HTTP header.

sascha_sl 7y ago
Hey CJ. I don't think that graph will ever be readable without vendor-specific hacks applied for every piece of software participating. AS will meet the same fate as XMPP. Some very core features might work, but the diversity in user agents and servers and their quirky implementations will ultimately be to its detriment. Maybe that's leftover pessimism from the time I participated in the XMPP WG. I'd love to be wrong. I have a lot of respect for implementing AS in Go. I tried and didn't even finish my relay implementation. It was just too counter to the Go core competency and mindset. Or I'm just not a fan of wrangling interface{}s around.
- cjslep 7y ago
  Hey! I totally understand the pessimism. I am untainted by XMPP for better or worse. I started typing out a reply on my phone but I think I need to sit with a keyboard and just make a blog post on it -- I hope you don't mind a wait. I hope I'll do a fair job characterizing the problems you identity and give them my alternate outlook.
thejohnconway 7y ago
ActivityPub is too complicated and loosey-goosey. There are a couple of dozen partial implementations out there, but most of them don't federate properly or at all (which I thought was the entire point of the spec!). Ideally such a standard should be really easy to implement, so we get true diversity, and democratisation, but implementing ActivityPub is a nightmare. Of course it doesn't help that the test suite has been down for months. https://test.activitypub.rocks https://test.activitypub.rocks
- 7y ago

WorldMaker 7y ago

In this particular case, this RFC isn't Standards Track, it is merely Informative, presumably partly because it isn't normative (it's not about behavior but about conventions/hints).

lightgreen 7y ago
This RFC reserves an http header name. Is is not just informative.
- WorldMaker 7y ago
  Many capital-I Informative RFCs reserve things like HTTP Header Names. Some of the easiest examples are April Fools RFCs that reserve all kinds of things, and while some people do like to use HTTP 418 I'm a Teapot (https://http.cat/418 https://http.cat/418), that's not a capital-S Standard. The IETF has workflows for Informative things versus Standard things. It's still useful to "reserve" things in Informative RFCs in case the RFC later moves to the Standards Track. Or also as some of the April Fools RFCs seem to indicate the internet takes its jokes pretty seriously and you never know when an Informative thing maybe adopted just because it was interesting to some developer for some project.