Greg Scallan

@politipet@piaille.fr @Flipboard@flipboard.social @cobrate@mastodon.social @CourrierInter@flipboard.com@Flipboard@flipboard.social and all our desk accounts are already bridged. On Bluesky we're @flipboard.flipboard.social.ap.brid.gy and the desks follow the same pattern (newsdesk, techdesk, sciencedesk, culturedesk, artphotosdesk) The gap you found is on publisher accounts at flipboard.com. Bridging there is per account and opt-in, since many publishers already have their own Bluesky presence and a bridged copy would duplicate it. Some have opted in (heise online, Flipboard Brasil), @CourrierInter@flipboard.com hasn't yet. We'll look into making that opt-in easier for publishers. Until then, quotes of unbridged posts show as link cards on Bluesky, which is Bridgy Fed's fallback (I think, from what I can tell)

@welshpixie@mastodon.art @mike@flipboard.social I appreciate you laying that out clearly. To be specific about what Surf does: when a user logs into Surf with their Mastodon account, they're opting in to use Surf as their client. The posts they see are public posts accessed through the standard Mastodon API — the same way Ivory, Ice Cubes, or any third-party client works. We don't scrape or redistribute posts outside of that user's authenticated session. Where Surf differs from a traditional client is that it also shows content from other networks like Bluesky alongside Mastodon content. But the Mastodon content is accessed through the same API every client uses, on behalf of a user who chose to log in. I respect your community's values around consent and I understand the concern. I also want to be 1000% transparent on what we are doing and how it works. Privacy is extremely important to me (and us) and being transpararent about how this works is a critical component to that endeavor. Happy to keep the conversation going if you have specific scenarios you'd like me to address.

@paul@digitalstuntfactory.com @surf@flipboard.social So, right now, federating Surf would be difficult. Our custom feeds are really aggregators of federated posts as opposed to something federated already. There is a group looking at how to standardize this called ActivityPub Remixing and Aggregation Task Force so I think we need to see where that goes. Regarding an open source instance, that is on my todo list. I'd like to open source the client and have a reference server implementation ... not sure the appetite people have for this, it would be a nontrivial undertaking.

@fasnix@fe.disroot.org @surf@flipboard.social Currently it is not. The backend is built on 16 years of tech at Flipboard which would be difficult to OS to be honest without major work done. We've thought about building a streamlined backend and then open sourcing the client. But so far, that has been just a thought.

@stefan@stefanbohacek.online @tchambers@indieweb.social @Flipboard@flipboard.social ok rolled out ... let me know if it does not work the way you expect.

@stefan@stefanbohacek.online @tchambers@indieweb.social @Flipboard@flipboard.social good idea, let me look into it

@OliviaVespera@spacey.space @mike@flipboard.social @welshpixie@mastodon.art @surf@flipboard.social For fediverse discovery and search, Surf federates with flipboard.social, which in turn federates with flipboard.com (we have our own activity pub implementation there) — so fediverse content reaches us through standard ActivityPub federation. We do run a "headless" surf.social Mastodon instance to allow surf users to interact with the fediverse.

@joshix@fosspri.de @voxel@infosec.space @hellomiakoda@pdx.social @surf@flipboard.social our AP implementation on surf.social is mastodon. Our AT implementation is bluesky PDS. We also run flipboard.social mastodon instance.

@David@setouchi.social @mike@flipboard.social @surf@flipboard.social You should be frustrated. I agree, the muted example is something we should be able to take care of client side. Posts not showing up on Mastodon will ALWAYS be an issue with the way Activity Pub works, unfortunately. Unless every server that hosts people you follow relays with us not just posts but reboosts, we can't do that. Maybe a FASP will emerge one day for "big fedi" to support this.

@hellomiakoda@pdx.social @joshix@fosspri.de @surf@flipboard.social We support the Mastodon style discoverable, indexable and noindex. Are you looking for more than that? I'm more than happy to add your mastodon accounts to a never ever ever ever ever show up list.

welcome!

@blogamf @tdf @greg@flipboard.com Rolled out a fix, let me know if it continues to happen

@joshix@fosspri.de @surf@flipboard.social done ... changed the "View source code" link to reference our fork

@joshix@fosspri.de @surf@flipboard.social Yes, you can see the modifications here at the publicly available fork https://github.com/Flipboard/mastodon

@joshix@fosspri.de @surf@flipboard.social good callout, you are right, that is an easy change, I will do that.

@voxel@infosec.space @hellomiakoda@pdx.social @joshix@fosspri.de @surf@flipboard.social I'm NOT a lawyer. C-252/21 ruled that data being "manifestly made public" (Art. 9(2)(e)) doesn't automatically authorize all processing of it — the scope and purpose still matter. surf.social is a mastodon instance (and other stuff). Sounds like you are asking the legal basis for a mastodon instance to process the personal data of users on other mastodon instances? I would probably say under Article 6(1)(f) legitimate interest. For federation with other instances: receiving and displaying public posts from the fediverse is the core function users expect. My understanding in this case courts tend to favor this interest when you're processing data people intentionally published to a federated network. But ... as I said ... I'm NOT A LAWYER ... if you would like your data removed, just say the word.

@welshpixie@mastodon.art @mike@flipboard.social Good question! Surf works differently from instance-to-instance federation — it's a multi-network client that connects to Mastodon, Bluesky, and other networks independently. So your instance-level blocks of Threads and the Bluesky bridge are fully respected within Mastodon's own federation, but Surf surfaces content from those networks on its own, outside of that federation layer. There is a Mastodon API (/api/v1/instance/domain_blocks) that can expose an instance's blocklist, but only if the admin has chosen to make it public — many instances don't. And even where it is available, it raises a broader question for us: Surf's purpose is to bring multiple networks together in one place, so honoring instance-level federation blocks in a non-federation context is something we'd need to think carefully about. It's actually a topic that has popped up quite a bit lately that I don't have a reliable solution for that doesn't raise even more questions.