Recent searches
Search options
in calmness @smallcircles@social.coopReminder: AS/AP-based suffers from #BallOfMud based ad-hoc expansion unless we find common practices and stick to them. Collaboration across a commons is essential here. Just coding your app with custom #ActivityPub protocol extension is contributing to #ProtocolDecay and increasing complexity to facilitate broad #interoperability.
The #FEP process and #SocialCG are where collective effort and proactive participation can improve #fedi for all. We need a bottom up standardization process.
@smallcircles it's possible that standards can be an emergent characteristic of building and experimentation.
My approach to building policy and standards (something I do a lot in my day job) - particularly for unproven or new technologies - is to start by building a proof-of-concept. Figure out what works. Then engage the community to refine and standardize.
We're in that PoC stage with a lot of things right now. Premature standardization could put us in a much worse position than allowing for the organic development of the ecosystem.
@jdt I agree, and am also deeply interested in emergence and how to facilitate that reliably so it turns into healthy evolution and adaptability to changing needs over time.
Interesting discussions are on matrix chat and social coding forum, looking at ideas and vision for a next-gen fedi, kicked off by @helge
Premature standardization as the name says is an anti-pattern, but so too is post-facto documentation of what has become de-facto standard in the fediverse installed base.
So it is a balancing act.. unless the system is primed to not find a natural balance, which imho is the case in current ASAP fedi.
I semi-jokingly referred to it as the "as soon as possible" fedi, an intermediary stage I suppose to the next-gen fedi that is still not tapped into well enough, and we risk squandering potential and opportunity and giving ample time for corporate web to catch up and make things bland and exploited, let alone very unsafe for diverse fedizen groups.
@smallcircles the only question is what we do with the existing applications that are based on mastodon.
with #rdfpub i'm at the very beginning of federation and have been surprised countless times.
i'm very excited to see what else i come across.
If the commons accepts its open standards based, as requirement to assure its openness, and people building apps and services for that commons claim to adhere to these standards, then they should be willing to participate and accomodate, sometimes make concessions for the greater good.
Now any FOSS project is entitled to go anywhere it wants. They are autonomous. But the commons should not hang their head and go into unsustainable direction because of a post-facto interop leader.
See also the 5 forces I see that determine interop on the ASAP "as soon as possible" fedi and tooted something about:
the only question is what we do with the existing applications that are based on mastodon.
They will simply get a degraded experience over time, as they don't support many of the features being developed by other platforms.
We already have this issue with Hubzilla vs. Mastodon, and Nomad/Zot Protocol vs. ActivityPub. Mastodon and ActivityPub simply don't support a lot of the features we have. It will eventually be the same when other platforms implement a common way of serving threaded conversations in ActivityPub, but Mastodon sticks with non-threaded conversations. There will be a feature gap.
@scott indeed. As it should be. Ditch that post-facto interoperability laziness, if you care about fedi.
It remains exciting!
We had a nice, detailed discussion about FEP-0036 this morning. I simply have a problem with the restriction of as:Public:
Hi @naturzukunft @scott,
is this the pentagonal wheel for what is already the case for the 'normal' web?
Either soft declaration (robots, noindex) or hard enforcement (authorisation), isn't it?
On a per-post basis, right? The rest is a local concern of the server.
It also can be on an account basis.In Hubzilla, you can set post-level permissions that control who can see individual posts, but then we also have account level setting that can opt-out of search engines.
If you opt-out of search engines, we include soft declarations on your channel that tell search engines to not index the page (which includes your posts). Hubzilla also has a built-in search function, and opting out of search would also hide your posts there as well. But people could still go to your channel and see your public posts.
Something like FEP-0036 would allow platforms like Hubzilla to communicate with other platforms that an account does not want their posts to show up in their built-in search, if they have one.
@scott that's definitively for the user agent and page content, or also the wire format when handing out actor profiles?
the only question is what we do with the existing applications that are based on mastodon.
When we get to the point where threaded conversation platforms dominate, and there are more blogs with long form content on the fediverse, Mastodon might have to create an inbox with multiple views. For microblogging, they display incoming posts the same way they do now. But they might need to add a threaded conversation view and a blog reader view to handle long form posts and their comments.
This would allow them to stay true to their microblogging roots, by only supporting outgoing short-form posts, yet their inbox/reader view can support a variety of content types.
In a way, that would make it into two apps, a microblogging platform and a fediverse reader.