NodeBB

@reiver@mastodon.social thanks, and if I'm presenting (which is up to you I think!) do I have to buy a ticket to FOSSY too?

@fedicon@techhub.social I still don't understand which two days are FediCon?

@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.

Good question — in my opinion, 7888 serves as a gentle introduction into the entire concept of conversational contexts. It's meant to be descriptive in order to capture the variety of existing implementations of context that are found in the wild (e.g. Pleroma context which doesn't resolve, contexts that are not URLs, etc.)

Each subsequent FEP "down the tree" (or up, depending on how you look at it) narrows the scope and upgrades verbiage in order to enable additional functionality.

Specifically pertaining to 11dd:

• Ownership is explicitly defined and is now a requirement, 7888 mentioned attributedTo and context ownership as examples only.
  • This upgrade was done to set the stage for subsequent FEPs for forking, merging, moving, etc.
• Activities should be sent to the context owner. This is identical to 7888, but re-stated as a reminder.
• A specific recommendation for inheritance is included (adopt the immediate parent's context, more if able), while 7888 allows for one to drop context altogether, inherit, or create your own.

This is not to say that 7888 is deficient in any manner. On the contrary, it's working entirely as intended!

In practice, Lemmy has adopted 7888, but at this time will not adopt 11dd. @nutomic@lemmy.ml creates a context local to the instance, for each post because each instance is expected to be the canonical representation of the context, even if they are cached representations of remote federated content.

It means it would preclude Lemmy from adopting further upgrades like forking/merging/moving/locking, but it doesn't mean they are wrong in doing so.

@trwnh@mastodon.social

> I don't quite understand what "its own context" means here.

This line was lifted from an earlier draft where additional examples of defining ones own context, removing a context, or inheriting a context, is spelled out explicitly.

I realized after drafting that that was already more or less described in 7888 and so brevity won out.

I will need to reword that.

@boris@cosocial.ca giving us ATProto 101.

Good, I have no idea what any of this is.

@chris@mstdn.chrisalemany.ca talking about starting up SocialBC is inspiring!

Makes me wonder if something like this could happen in Ontario... esp. rural communities.

@j12t@j12t.social "now I realize I am standing between you and Lunch"

Poor Johannes, at FOSDEM he was standing between us and dinner, too.

@j12t@j12t.social dropping truth bombs about fedi vs the greater social media landscape

@trwnh@mastodon.social I think what @quillmatiq@mastodon.social is getting at is less that decentralization isn't important (because it is!) but more that UX friction is a surmountable barrier for adoption, and arguably more important now than later.

We can debate endlessly about which protocol is GOAT, or how to define decentralization...

A shout-out to @gabboman@app.wafrn.net and it's native bridge to BlueSky

Reminds me of the work @jesseplusplus@mastodon.social is doing with Decodon/@frequency@frequency.app!

Evan talking about AOL. @mike@flipboard.social would be proud.

First up, the keynote by @evan@cosocial.ca

Let's get this party started!

Day 1 of FediCon

@silverpill@mitra.social nice job! Congratulations on the release now you must maintain it for free forever.

That's odd, we don't produce bbcode, where did it come from?

Hey @rimu@piefed.social thanks for responding (and sorry for the late reply!)

I am not married to the Announce([Article|Note|Page]) approach, so I am definitely open to Create([Article|Note|Page]) with a back-reference. I think I went the former direction because there is a known fallback mechanism — the Announce is treated as a share/boost/repost as normal. However, sending the Create also is fine I think.

1. However, do we need a backreference? In my limited research, it seems that Piefed, et al. picks the first Group actor and associates the post with that community. If I sent over a Create(Article) with two Group actors addressed, could Piefed associate the post with the first, and initiate a cross-post with the remaining Group actors?
2. Secondly, is how to handle sync. 1b12 relies on communities having reciprocal followers in order for two-way synchronization to be established. On my end since I know it is cross-posted I will now send 1b12 activities to cross-posted communities, but can Piefed, et al. send 1b12 activities back as well, in the absence of followers?

cc @andrew_s@piefed.social @nutomic@lemmy.ml @melroy@kbin.melroy.org @bentigorlich@gehirneimer.de

@projectmoon@forum.agnos.is basically, yes. It would be a little too involved to upend the entire system to support multiple cids per topic — a lot of our existing code relies on cid being a single value.

This would be an add-on logic of sorts, where each topic has a canonical category, but can also be cross-posted to other communities/categories.