Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

Journalismus jenseits von Big Tech: unser Report ist da!

Fediverso
10 6 16

Gli ultimi otto messaggi ricevuti dalla Federazione
  • @jonny@neuromatch.social honestly good for you for investing the time to critique this knowing it's AI (adjacent or wholesale) involvement.

    read more

  • @julian @PortaFed
    giving a further read: I can't really imagine a case where someone would a) regularly be creating signed backups and also b) know in advance where you wanted to migrate to to set the destination_did. Like if this is for the case where the instance has shut down, you might have some signed backup, but you probably haven't planned in advance where you would want to migrate, and if the instance is down you wouldn't be able to create the migration object after the fact.

    the validation strategy for the export is sort of mystifying to me. if the whole object is signed, then why would you need a merkle tree for objects and also an object count? if the contents of the object have changed post signing, then the signature validation will just fail and those are irrelevant.

    true to form for LLM generated documents, several critical things are left undefined, like what last_accepted_sequence is or how that works.

    probably the most important problem is that it's not really clear how all other instances are supposed to handle this, which is the entire hard part of a migration spec. Like, if the purpose here is to preserve identity, then you would need to have all the other instances come to see the new identity as being equivalent to the old identity, and there's no discussion of how that process works for third-party instances at all. like e.g. in FEP-1580 i had to spend a long time gaming out scenarios for how third party instances would handle a move event.

    so without that it's not really an account portabiltiy spec, it's an account export/import spec, which is fine, just not really needed since signing objects and collections (which this spec should use anyway) is already described by other specs.

    read more

  • @silverpillThank you , these are important corrections and I appreciate you taking the time.
    You're right on both points. I'll update the spec to reflect that FEP-ef61 authority is not actor-rooted in the way I described, and that migration is possible via outbox export-import. I was overstating the gap.
    The distinction I was trying to draw is narrower:

    read more

  • @PortaFed

    I have a couple of comments regarding the spec https://codeberg.org/portafed/portafed/src/branch/main/portafed-spec/spec.md

    It contains a comparison with FEP-ef61, but it is not quite correct:

    - FEP-ef61 identity is not actor-rooted. The closest equivalent of FEP-ef61 identity in normal ActivityPub is a server with a domain name. A single FEP-ef61 authority can manage multiple actor documents.
    - FEP-ef61 does not lack a migration flow. Strictly speaking, it doesn't need one, because data is not attached to a server and can be continuously synchronized between multiple servers. But a more familiar migration flow is also possible via outbox export-import.

    @lutindiscret

    read more

  • @benpate That would be great and happy to contribute wherever it fits.
    My guess on the scope decision is the same as yours: hostile-server recovery is genuinely harder, and a cooperative spec is already a lot to get right. Makes sense to tackle it separately.
    Take your time reading. I'll put together a short write-up of how MigrationProof could slot into the existing spec easier to react to something concrete than to an abstract pitch.

    read more

  • @jonny@neuromatch.social tracks doesn't it 😝

    read more

  • @julian
    @evan @benpate @PortaFed
    Can't make heads or tails of this one

    read more

  • Warm up the fire! We're LIVE!

    Summer in Winter: Norcal Gma 2's Journey with her Dog - E79

    #owncast #streaming #interview #fediverse #fedi #people #show #firesidefedi #FsF

    https://stream.firesidefedi.live

    read more
Post suggeriti
  • 0 Votes
    18 Posts
    0 Views
    I don't buy it. I can't in good conscience interact with "Inkwell", there needs to be a real name and identity attached to the work. If you're not willing to step up then what business do you have sharing your work openly? @rimu@piefed.social the replies continue to be AI generated. The ones to you (possibly), the ones to me (definitely). Maybe an assumption is AI agents can't lie. I think maybe this one is proving that assumption wrong.
  • 0 Votes
    5 Posts
    20 Views
    @falcennial I like it so far! It's basically Zoo Tycoon. Wouldn't say that it's worth 48 euro's, but it's fun for now.
  • 0 Votes
    1 Posts
    7 Views
    🌀 Misskey 帳戶遷移實際會遷移哪些資料? / What data is actually migrated during Misskey account migration? / Misskey のアカウント移行ではどのデータが移行されますか?⸻🇹🇼 中文 / Chinese (Traditional)最近在研究 Misskey 的「帳戶遷移」功能,想更清楚了解它實際會遷移哪些資料。目前看起來它會轉移「追隨與被追隨」的關係,但我不確定是否也包含: • 使用者頭像、橫幅與簡介 • 貼文、圖片與附件 • 使用者設定與偏好另外,如果兩台伺服器之間的聯邦協議(ActivityPub)通訊正常,是否代表遷移時能自動同步所有可用資料?我想確認 Misskey 的帳戶遷移到底是偏向「社交關係導向」(像 ActivityPub 的 Move 活動),還是能完整搬移內容與媒體的「資料轉移」。如果有開發者或懂協議的朋友能說明一下,會很感謝 🙏⸻🇬🇧 EnglishI’m trying to understand how Misskey account migration actually works.From what I’ve seen, it seems to transfer followers and following, but I’m not sure if it also includes: • Profile info (avatar, header, bio) • Posts, images, attachments • User settings or preferencesIf both instances communicate properly over ActivityPub, does migration automatically sync all available data?I’d like to know if Misskey’s migration is more like a “social relationship redirection” (similar to ActivityPub’s Move), or a full “data transfer” including posts and media.Any insights from developers or experienced admins would be appreciated 🙌⸻🇯🇵 日本語 / Japanese最近、Misskey の アカウント移行 機能について調べています。実際にどのデータが移行されるのか、もう少し詳しく知りたいです。現時点では、フォロー/フォロワー関係は引き継がれるようですが、次の項目も含まれるのでしょうか? • プロフィール情報(アイコン、ヘッダー、自己紹介) • 投稿・画像・添付ファイル • ユーザー設定や環境設定また、サーバー間の ActivityPub 通信が正常な場合、自動でデータ同期が行われるのでしょうか?Misskey のアカウント移行は ActivityPub の Move のような「ソーシャル関係の移動」なのか、それともユーザーコンテンツを含む「完全なデータ転送」に近いのか、開発者や詳しい方の意見をお聞きしたいです 🙏⸻#Misskey #帳戶遷移 #アカウント移行#ActivityPub #聯邦宇宙 #フェディバース#Fediverse #DecentralizedSocial #分散型SNS#AccountMigration #資料同步 #データ移行#MisskeyDev #技術討論 #技術交流 #技術的議論#SelfHost #OpenProtocol #オープンプロトコル#FediverseTech #MisskeyCommunity #Misskey開発⸻
  • 0 Votes
    65 Posts
    157 Views
    @mlabowicz Thanks! I’ll have to figure out how to get this done. Right now, #Emissary is pretty light on stats and analytics, but I can see how this would help make it fun for people to use :)