Technical Discussion

@tesaguri @silverpill yeah, I'm not sure this is a problem. I think we actually want to have support for static sites.

trwnh@mastodon.social Yes you're right, some messiness is bound to happen. I'm not trying to force all implementations into a specific inheritance pattern, that's why it's a "should", not a "must". Even then one of my concerns is that while in an ideal scenario, everybody inheriting their parent context leads to an entire collection all referencing the same context... in reality a lot of messiness will occur, objects will reference other contexts all over the place, etc. At the end of the day it's best effort, and if we are able to handle all that and still get to a point where backfill is achievable, then that's a win in my books. > it depends on how much you embrace the idea of each publisher being allowed to make their own claims (and how much you allow "clean up" after the fact) Part of me would like this to not happen, but it is unavoidable.

@tesaguriI feel a bit sorry about losing the possibility of hosting AS feeds on a simple static site for consumption by AP clientsI don't think we lose it. As long as site administrator doesn't publish untrusted AS documents there, the site will work.

@thisismissem I think this solution is too cumbersome, so it shouldn't be the default recommendation. But I will mention it in the FEP because some applications may need to allow arbitrary JSON uploads, as @tesaguri pointed out.

@trwnh who are these "others" that have issues with content negotiation?The target for my software - this particular one I gave the icon example from - are browsers. And in a browser this content negotiation works perfectly fine, have a look see -> https://releases.bruta.linkCan you see the icon? You can. Can you open the icon in the browser in a new tab and still see it. Yes you can. Can you use curl on the icon URL, yes, and as it defaults to json, you get the JSON-LD representation. I think that's good enough for me. I accept that it's not for you and wish you good luck with the software that you're developing. I'll stop engaging now.

fedify@hollo.social congrats! When we launched version 2 it was done similarly... much changed in the backend but the day to day UI remained exactly the same. It was a major release because of how much work and refactoring went into it, and we said "if you don't notice anything different it means we did our job right"

@julianif your app notifies you of new replies without a direct mention I'll stop tagging you tooInclusion in to or cc is enough to generate a notification.

@evan indeed, very nice!

Ah. Yes, I'll add that. Thanks!

dev@social.musing.studio does this mean that we will see both a title in name and in content? That would be a duplication... Not the end of the world by any stretch, of course.

Was just coming to say what silverpill@mitra.social did!

dansup@mastodon.social that's huge news Dan! Congrats on the launch and the code release

@evan I don't think it's going to take a long time. If you have a file host you'd like to propose that we can mirror the Codeberg fediverse/fep repo to, then by all means, propose one.In any case, the lack of availability of a response over HTTPS should not be taken to mean that a context "doesn't work". Newer W3C specs recommend preloading contexts with known content+hashes ahead-of-time: https://www.w3.org/TR/vc-data-model-2.0/#base-context> Implementations MUST treat the base context value [...] as already retrieved

silverpill@mitra.social why do I get irrationally nervous whenever a new test by helge@mymath.rocks drops?

Also at this pace I might run out of things to document if my NGI0 grant proposal will be approved, as a lot of the deliverables I set are for decreasing the friction new developers will have in using the library, which relies heavily on good documentation. It's a nice problem to have I guess.