# Fork \`memory\`? As \`memoria\`?

**URL:** <https://discourse.haskell.org/t/fork-memory-as-memoria/11777>\
**Category:** Learn\
**Created:** [April 5, 2025, 7:01pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777 "2025-04-05T19:01:15Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![mpilgrem](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpilgrem/32/2529_2.png) [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)\
**Post date:** [April 5, 2025, 7:01pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/1 "2025-04-05T19:01:15Z")

</div>

I understand that there is a need to fork the popular [`memory`](https://hackage.haskell.org/package/memory) package, from version 0.18.0.

`memory` is a dependency of Stack and I have been thinking: “Perhaps I could step up and do that?” However, I have hesitated, thinking: “But surely there is somebody else better placed than me?”

So, I raise this topic here, in case others are thinking much the same, and also hesitating, for much the same reason.

The need for a fork arises because the maintainers of `memory` do not wish to develop it further but its primary author also does not want to introduce other people as maintainers, for the reasons that he has set out elsewhere. I’m not raising this topic to debate those reasons, but with the aim of moving things forward.

If I published a fork, I am thinking that `memoria` would be a good name. It is Latin for _memory_ and it chimes with the word for memory in a number of European languages.

---

<div class="post-metadata">

**Author:** ![hellwolf](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hellwolf/32/3020_2.png) [@hellwolf](https://discourse.haskell.org/u/hellwolf)\
**Post date:** [April 6, 2025, 5:41am UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/2 "2025-04-06T05:41:23Z")

</div>

or just… memory2 ? 🙂

---

<div class="post-metadata">

**Author:** ![bmobn00b](https://avatars.discourse-cdn.com/v4/letter/b/ecccb3/32.png) [@bmobn00b](https://discourse.haskell.org/u/bmobn00b)\
**Post date:** [April 6, 2025, 5:57am UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/3 "2025-04-06T05:57:42Z")

</div>

I suggest migrating libraries that use `memory` to alternative libraries(e.g. Base16, Base32, or Base64 encoding). Features without replacements could be divided into smaller libraries.

---

<div class="post-metadata">

**Author:** ![eldritch-cookie](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/eldritch-cookie/32/4130_2.png) [@eldritch-cookie](https://discourse.haskell.org/u/eldritch-cookie)\
**Post date:** [April 6, 2025, 7:03pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/4 "2025-04-06T19:03:18Z")

</div>

if you believe you can either maintain the package or add maintainers to do so for you then you probably could just publish a fork. while maybe someone will even then eventually publish a fork, a chance of having 2 forks is better than a chance of having 0

---

<div class="post-metadata">

**Author:** ![mpickering](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpickering/32/4585_2.png) [@mpickering](https://discourse.haskell.org/u/mpickering)\
**Post date:** [April 7, 2025, 1:02pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/5 "2025-04-07T13:02:30Z")

</div>

What does `stack` use from the `memory` package? I would also advise to migrate those uses to other libraries rather than to maintain a fork.

---

<div class="post-metadata">

**Author:** ![Vlix](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/vlix/32/1551_2.png) [@Vlix](https://discourse.haskell.org/u/Vlix)\
**Post date:** [April 7, 2025, 2:51pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/6 "2025-04-07T14:51:01Z")

</div>

For the [password](https://hackage.haskell.org/package/password) / [password-types](https://hackage.haskell.org/package/password-types) packages, we’re mostly only using `memory` because it’s one of the few packages I’ve found to have a constant time equality function for Bytes(trings).

If we can find a different package (or `bytestring` could get one) then we wouldn’t need the `memory` dependency anymore.

---

<div class="post-metadata">

**Author:** ![mpilgrem](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpilgrem/32/2529_2.png) [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)\
**Post date:** [April 7, 2025, 8:20pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/7 "2025-04-07T20:20:28Z")

</div>

My motivation was not so much ‘_because_ Stack depends on `memory`…’ but more ‘_as_ Stack depends on `memory`…’. However:

Stack uses `Crypto.Hash.hashWith` from the `crypton` package (the fork of `cryptonite`, now maintained by Kazu Yamamoto) to hash bytes into a digest - and `crypton` depends on `memory`.

---

<div class="post-metadata">

**Author:** ![sclv](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/sclv/32/71_2.png) [@sclv](https://discourse.haskell.org/u/sclv)\
**Post date:** [April 8, 2025, 12:00am UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/8 "2025-04-08T00:00:07Z")

</div>

I think porting `crypton` off memory would be a big win, as it uses a small portion of it, and a lot of things use crypton.

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [April 8, 2025, 5:28am UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/9 "2025-04-08T05:28:05Z")

</div>

I’m a fan of forking and do that once in a while, e.g.:

- [xz: LZMA/XZ compression and decompression](https://hackage.haskell.org/package/xz)
- [yaml-streamly: Support for parsing and rendering YAML documents.](https://hackage.haskell.org/package/yaml-streamly)
- [shortbytestring: Additional ShortByteString API](https://hackage.haskell.org/package/shortbytestring)

However, I hope you have a maintenance strategy. Just forking and leaving it on life support is probably not a good idea, especially for this type of package.

“Community maintenance” is mostly a pipe dream, imo. Drive by contributions mess up the original design and no one really establishes deep expertise.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [April 8, 2025, 7:18am UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/10 "2025-04-08T07:18:25Z")

</div>

> “Community maintenance” is mostly a pipe dream, imo. Drive by contributions mess up the original design and no one really establishes deep expertise.

Agreed.

Security is a full-time job, and often a thankless one at that. So relying on _“wandering minstrels”_ or _“giggers”_ isn’t only impractical, it can give a false sense of security, as amusingly illustrated in this XKCD rendering ([chosen by](https://github.com/commercialhaskell/stackage/issues/7336#issuecomment-1986754809) the maintainer of `cryptonite` and `memory`):

![XKCD - Dependency](https://imgs.xkcd.com/comics/dependency.png)  
([source](https://xkcd.com/2347/))

with the last/only security _“minstrel”_ or _“gigger”_ being some other random person in Nebraska.

That a full-time security taskforce for Haskell wasn’t available to take charge of `cryptonite` before it was forked is unfortunate: that is now history. But how many more times will that history be repeated:

- ~~`memory`~~
- `memoria`
- `memoriam`
- `memorable`
- `memorandum`
- `memorabilia`
- `rememorative`  
⋮

until that taskforce is established?

[https://eu.swi-prolog.org/pldoc/man?section=crypto](https://eu.swi-prolog.org/pldoc/man?section=crypto)

---

<div class="post-metadata">

**Author:** ![mpickering](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpickering/32/4585_2.png) [@mpickering](https://discourse.haskell.org/u/mpickering)\
**Post date:** [April 8, 2025, 11:37am UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/11 "2025-04-08T11:37:48Z")

</div>

Which hashes in particular? It seems SHA-1 and SHA-256 from searching the source code from github.

I think people generally use `cryptohash-*` libraries for a simple dependency. It seems that `cryptohash-sha256` is already in the dependency closure of stack and there is the `cryptohash-sha1` package which provides a `SHA-1` hash implementation.

---

<div class="post-metadata">

**Author:** ![mpilgrem](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpilgrem/32/2529_2.png) [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)\
**Post date:** [June 7, 2025, 3:45pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/12 "2025-06-07T15:45:01Z")

</div>

Thanks to everyone for the advice. I’ve been tinkering with my idea but come to appreciate that the more fundamental question is the maintenance (that is, lack of maintenance) of the `basement` package. (@Bodigrim had warned me that was the case before I started, but I had not appreciated its significance.)

Stack depends on packages that depend (like almost 2,000 others on Hackage alone) on `tls`, which depends on (maintained) `crypton`, which depends on (unmaintained) `memory` and, directly and indirectly, on (unmaintained) `basement`.

(EDIT: My tinkering is in the `main` branch of [https://github.com/mpilgrem/memoria.](https://github.com/mpilgrem/memoria.))

---

<div class="post-metadata">

**Author:** ![Bodigrim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bodigrim/32/1457_2.png) [@Bodigrim](https://discourse.haskell.org/u/Bodigrim)\
**Post date:** [June 7, 2025, 4:00pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/13 "2025-06-07T16:00:17Z")

</div>

> [@mpickering](#):
>
> What does `stack` use from the `memory` package? I would also advise to migrate those uses to other libraries rather than to maintain a fork.

There are 250+ libraries depending on `memory` directly and thousands more indirectly. I don’t think it’s viable to suggest all of them to migrate to a different API. Even migration to a like-for-like fork will be a challenge.

---

<div class="post-metadata">

**Author:** ![lorenzo](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/lorenzo/32/1294_2.png) [@lorenzo](https://discourse.haskell.org/u/lorenzo)\
**Post date:** [June 8, 2025, 1:54pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/14 "2025-06-08T13:54:31Z")

</div>

Is it not possible to do a hack age takeover instead?

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [June 8, 2025, 3:27pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/15 "2025-06-08T15:27:44Z")

</div>

Apparently not, without a visible (and potentially breaking) change of policy:

[Policy regarding taking over Hackage packages](https://discourse.haskell.org/t/policy-regarding-taking-over-hackage-packages/11121)

> [@](#):
>
> It does not give instructions for what to do if the maintainer can be contacted, doesn’t want to maintain the package, but also doesn’t want anyone to take it over.
> 
> With the `cryptonite` family of packages in particular [which includes `memory`], the original author has [taken the position](https://github.com/commercialhaskell/stackage/issues/7336) that:
> 
> - people may have used the package because they trusted the author,
> - the author, being no longer involved, can’t evaluate any new maintainer to be a suitable recipient of that trust,
> - therefore, no ownership transfer maintains / deserves the trust that the package may have originally carried.

(thanks to those who pointed out this connection I missed). [Hence my prior post](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/10). But the lack of maintenance of `basement` (as noted by **Bodigrim** ) now seems to be the bigger _“can o’worms”_…

---

<div class="post-metadata">

**Author:** ![mpilgrem](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpilgrem/32/2529_2.png) [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)\
**Post date:** [June 8, 2025, 4:29pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/16 "2025-06-08T16:29:31Z")

</div>

Unlike the other ’ Vincent Hanquez’ packages, Michael Snoyman is recorded as a co-maintainer of `basement`. I’m in touch with Michael to see if there is a way forward for `basement` that does not involve a fork under a different name. I’ve told Michael that I am willing to look after `basement`.

---

<div class="post-metadata">

**Author:** ![mpilgrem](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpilgrem/32/2529_2.png) [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)\
**Post date:** [June 21, 2025, 5:30pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/17 "2025-06-21T17:30:14Z")

</div>

@ApothecaLabs, given your comment [here](https://discourse.haskell.org/t/improving-memory-with-better-abstractions/12350/8) are you the somebody else better placed than me (that part is certain, as the maintainer of `botan`!) who might step forward to maintain a fork of `memory` (whatever that fork happens to be named)?

If you are but also wanted a co-maintainer to help with ‘janitor’ work, I would be happy to help out. My own tinkerings around the idea to date are at [GitHub - mpilgrem/memoria: Haskell library for memory and related abstractions](https://github.com/mpilgrem/memoria), in the `main` branch.

---

<div class="post-metadata">

**Author:** ![ApothecaLabs](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/apothecalabs/32/3215_2.png) [@ApothecaLabs](https://discourse.haskell.org/u/ApothecaLabs)\
**Post date:** [June 21, 2025, 5:38pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/18 "2025-06-21T17:38:21Z")

</div>

I would be willing to step up, though a co-maintainer would be most certainly be appreciated as well as sometimes I have a hard time responding to smaller issues sometimes so having someone to help keep things timely and clean keeps things humming along. Plus its good to have someone to bounce ideas off of lest my own head get too echoey 🙂

---

<div class="post-metadata">

**Author:** ![mpilgrem](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpilgrem/32/2529_2.png) [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)\
**Post date:** [July 5, 2025, 7:07pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/19 "2025-07-05T19:07:16Z")

</div>

It has occurred to me that `memory` could be forked under the name `Memory`. @ApothecaLabs and others, what do you think of the merits and drawbacks of that?

---

<div class="post-metadata">

**Author:** ![sclv](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/sclv/32/71_2.png) [@sclv](https://discourse.haskell.org/u/sclv)\
**Post date:** [July 5, 2025, 9:55pm UTC](https://discourse.haskell.org/t/fork-memory-as-memoria/11777/20 "2025-07-05T21:55:17Z")

</div>

Hackage now should prevent names that differ only in case, at least for new packages. (legacy ones are grandfathered in). This was implemented after it was raised that such “case-clash” packages are a common way in other ecosystems of introducing supply chain attacks.

[Next page](https://discourse.haskell.org/t/fork-memory-as-memoria/11777.md?page=2)