cross-posted from: https://lemm.ee/post/65824884

Hey everyone

We’re really sorry to say this, but lemm.ee will be shutting down on June 30, 2025.

What you need to know

As of now:

  • New user registrations are disabled
  • Creating new communities is disabled

What you should do:

  • You can export your settings at https://lemm.ee/settings to take them with you to another instance.
  • If you’re moving to another instance, consider adding a note to your lemm.ee profile with your new username. Your old profile will still be visible from other instances even after we go offline.
  • Alternatively, if you want to delete your lemm.ee profile, now is the best time to do it, so the deletion can federate out before we go offline.
  • If you’re one of the folks supporting us with a recurring donation, please remember to cancel it (Ko-Fi donations should have been cancelled automatically already). Our leftover funds are already enough to cover our bills for next month, so we can keep things running without any more support.

Because of how Lemmy is built, everything posted on lemm.ee will still be accessible from other instances, even after we go offline.

Why this is happening

The key reason is that we just don’t have enough people on the admin team to keep the place running. Most of the admin team has stepped down, mostly due to burnout, and finding replacements hasn’t worked out.

The sad reality is that while there are a lot of great people on Lemmy, there are also some who use the platform to attack others, stir up conflict, or actively try to undermine the project. Admins are volunteers who deal with the latter group on a constant basis, this takes a mental toll. Please understand why our admins chose to step down, and be kind to the admins on whatever instance you decide to join.

We know this sucks. We’re genuinely sorry it’s ending like this. Thank you to everyone who spent time here and helped make it better.

– lemm.ee team

  • The Picard Maneuver@lemmy.worldEnglish
    98·
    3 days ago

    What a loss. =(

    It’s a strange quirk of lemmy that we will continue to be able to see content from lemm.ee even after they’ve shut down. It’ll feel like seeing ghosts.

    • deus@lemmy.worldEnglish
      66·
      3 days ago

      A lot of the internet has been lost to time already so I actually appreciate this place having this kind of permanence.

        • FundMECFS@lemmy.blahaj.zoneEnglish
          5·
          3 days ago

          Your correct. Lemm.ee’s ghosts will only live on in the instances around during it’s life.

          Kind of like humans after they die. You still live on in the memories of those who knew you.

              • irelephant [he/him]@lemmy.dbzer0.comEnglish
                4·
                2 days ago

                Interesting, what browser are you using?

                Anyway, its written in markdown.

                The contents of FEP-ef61.

                FEP-ef61: Portable Objects

                Summary

                Portable [ActivityPub][ActivityPub] objects with server-independent IDs.

                Motivation

                Usage of HTTP(S) URLs as identifiers has a major drawback: when the server disappears, everyone who uses it loses their identities and data.

                The proposed solution should satisfy the following constraints:

                • User’s identity and data should not be tied to a single server.
                • Users should have a choice between full control over their identity and data, and delegation of control to a trusted party.
                • Implementing the solution in existing software should be as simple as possible. Changes to ActivityPub data model should be kept to a minimum.
                • The solution should be compatible with existing and emerging decentralized identity and storage systems.
                • The solution should be transport-agnostic.

                History

                Nomadic identity mechanism makes identity independent from a server and was originally part of the Zot federation protocol.

                Streams (2021) made nomadic accounts available via the Nomad protocol, which supported ActivityStreams serialisation.

                FEP-c390 (2022) introduced a decentralized identity solution compatible with ActivityPub. It enabled permissionless migration of followers between servers, but didn’t provide full data portability.

                Requirements

                The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC-2119][RFC-2119].

                Identifiers

                An [ActivityPub][ActivityPub] object can be made portable by using an identifier that is not tied to a single server. This proposal describes a new identifier type that has this property and is compatible with the [ActivityPub] specification.

                ap:// URLs

                ap:// URL is constructed according to the [URI][RFC-3986] specification, but with a [Decentralized Identifier][DID] in place of the authority:

                ap://did:example:123456/path/to/object?name=value#fragment-id
\_/  \________________/ \____________/ \________/ \_________/
 |           |                |            |           |
scheme   authority           path        query     fragment
                • The URI scheme MUST be ap.
                • The authority component MUST be a valid [DID].
                • The path is REQUIRED. It MUST be treated as an opaque string.
                • The query is OPTIONAL. To avoid future conflicts, implementers SHOULD NOT use parameter names that are not defined in this proposal.
                • The fragment is OPTIONAL.

                [!NOTE] ActivityPub specification [requires][ActivityPub-ObjectIdentifiers] identifiers to have an authority “belonging to that of their originating server”. The authority of ‘ap’ URL is a DID, which does not belong to any particular server.

                [!WARNING] The URI scheme might be changed to ap+ef61 in a future version of this document, because these identifiers are not intended to be used for all ActivityPub objects, but only for portable ones.

                DID methods

                Implementers MUST support the [did:key] method. Other DID methods SHOULD NOT be used, as it might hinder interoperability.

                [!NOTE] The following additional DID methods are being considered: did:web, did:dns, did:webvh (formerly did:tdw) and did:fedi.

                DID documents SHOULD contain Ed25519 public keys represented as verification methods with Multikey type (as defined in the [Controlled Identifiers][Multikey] specification).

                Any [DID URL][DID-URL] capabilities of a DID method MUST be ignored when working with ap:// URLs.

                Dereferencing ap:// URLs

                To dereference an ap:// URL, the client MUST make HTTP GET request to a gateway endpoint at [well-known] location /.well-known/apgateway. The ap:// prefix MUST be removed from the URL and the rest of it appened to a gateway URL. The client MUST specify an Accept header with the application/ld+json; profile="https://www.w3.org/ns/activitystreams" media type.

                Example of a request to a gateway:

                GET https://social.example/.well-known/apgateway/did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/path/to/object

                ActivityPub objects identified by ap:// URLs can be stored on multiple servers simultaneously.

                If object identified by ap:// URL is stored on the server, it MUST return a response with status 200 OK containing the requested object. The value of a Content-Type header MUST be application/ld+json; profile="https://www.w3.org/ns/activitystreams".

                If object identified by ap:// URL is not stored on the server, it MUST return 404 Not Found.

                If object is not public, the server MUST return 404 Not Found unless the request has a HTTP signature and the signer is allowed to view the object.

                [!NOTE] This document describes web gateways, which use HTTP transport. However, the data model and authentication mechanism are transport-agnostic and other types of gateways could exist.

                Authentication and authorization

                Authentication and authorization are performed in accordance with [FEP-fe34] origin-based security model.

                The [origin][RFC-6454] of an ap:// URL is computed by the following algorithm:

                1. Let uri-scheme be the ap string.
                2. Let uri-host be the authority component of the URL.
                3. Let uri-port be the number 0.
                4. Return the triple (uri-scheme, uri-host, uri-port).

                And the origin of a [DID URL][DID-URL] is computed by the following algorithm:

                1. Let uri-scheme be the ap string.
                2. Let uri-host be the DID component of the DID URL.
                3. Let uri-port be the number 0.
                4. Return the triple (uri-scheme, uri-host, uri-port).

                Actors, activities and objects identified by ap:// URLs MUST contain [FEP-8b32] integrity proofs. Collections identified by ap:// URLs MAY contain integrity proofs. If collection doesn’t contain an integrity proof, another authentication method MUST be used.

                The value of verificationMethod property of the proof MUST be a [DID URL][DID-URL] where the DID matches the authority component of the ap:// URL.

                [!NOTE] This document uses terms “actor”, “activity”, “collection” and “object” according to the classification given in [FEP-2277].

                Portable actors

                One identity (represented by [DID]) can control multiple actors (which are differentiated by the path component of an ap:// URL).

                An actor object identified by ap:// URL MUST have a gateways property containing an ordered list of gateways where the latest version of that actor object can be retrieved. Each item in the list MUST be an HTTP(S) URL with empty path, query and fragment components. The list MUST contain at least one item.

                Gateways are expected to be the same for all actors under a DID authority and MAY be also specified in the DID document as [services][DID-Services].

                Example:

                {
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://w3id.org/security/data-integrity/v1",
    "https://w3id.org/fep/ef61"
  ],
  "type": "Person",
  "id": "ap://did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/actor",
  "inbox": "ap://did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/actor/inbox",
  "outbox": "ap://did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/actor/outbox",
  "gateways": [
    "https://server1.example",
    "https://server2.example"
  ],
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "created": "2023-02-24T23:36:38Z",
    "verificationMethod": "did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2#z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2",
    "proofPurpose": "assertionMethod",
    "proofValue": "..."
  }
}

                Location hints

                When ActivityPub object containing a reference to another actor is being constructed, implementations SHOULD provide a list of gateways where specified actor object can be retrieved. This list MAY be provided using the gateways query parameter. Each gateway address MUST be URL-endcoded, and if multiple addresses are present they MUST be separated by commas.

                Example:

                ap://did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/actor?gateways=https%3A%2F%2Fserver1.example,https%3A%2F%2Fserver2.example

                This URL indicates that object can be retrieved from two gateways:

                • https://server1.example
                • https://server2.example

                Implementations MUST discard query parameters when comparing ap:// identifiers and treat identifiers with different query parameter values as equal.

                Inboxes and outboxes

                Servers and clients MUST use gateways to deliver activities to inboxes or outboxes. Servers specified in the gateways property of an actor object MUST accept POST requests to respective gateway URLs.

                Example:

                POST https://social.example/.well-known/apgateway/did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/actor/inbox

                Delivered activities might be not portable. If delivered activity is portable (has ap:// identifier), the server MUST verify its [FEP-8b32] integrity proof. If the server does not accept deliveries on behalf of an actor, it MUST return 405 Method Not Allowed.

                ActivityPub clients MAY follow [FEP-ae97][FEP-ae97] to publish activities. In this case

    • nanook@friendica.eskimo.com
      2·
      2 days ago

      @The_Picard_Maneuver @FrostyTrichs I think this is a common attribute of the fediverse in general. Once a post has propagated to other sites, the non-existence of the originating site is not going to remove that post, but in some cases posts may contain references to images on the original site and the site that it propagated to may elect to reference images from the original site rather than store them locally. In that case, the new site will have the post but not images that it contained.