Interesting tool based on blocks to tag any document for photos you own. With app to allow access from any device. Blocks contains tags and links between them to organize all like a heap.
I haven't installed the self-hosted version yet to see how it can interact with an existing Obsidian vault. Next step.
Site: https://heaper.de/

all 22 comments

sorted by: hot top controversial new old
[–] 21 points 8 months ago (2 children)

Sigh....

That stupid way of explaining the license plan aside, are we again having to explain that we don't want our data locked into yet another db format?

  • source
  • hideshow 2 child comments
  • [–] 2 points 8 months ago (1 child)

    Can't really tell if that's the case or not. It looks like the base files you upload are stored on the filesystem as normal, and the "blocks" (metadata) is what's stored in the DB?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 8 months ago*

    Yes, that's what I get from that as well.

    I guess as long as users get some options for import/export/backup then it isn't that bad. I'm reading over the docs again and I don't think it's as bad as I initially read into it.

    This project would benefit from some documentation curation.

    Edit: which I suppose I could offer to help with to put my money where my mouth is.

  • source
  • parent
  • [–] 6 points 8 months ago

    Tags aren't categories you create β€” they're patterns you notice.

    Yes AI daddy 🀀

  • source
  • [–] [S] 6 points 8 months ago* (last edited 8 months ago) (2 children)

    Some notes:

    • This can be self-hosted. My working compose.yml is below
    • Free until August, and he has a discord for feedback, but I can't find the invite. It was in the live-stream he did.
    • He said in the stream that he's open to open sourcing the project. Just not there yet.
    • He admits the licensing is a little confusing. He stressed that self-hosting does not have a storage or block limit. Also, self-hosting is possible with all licenses (I think).
    • Supports macOS, Linux, Windows, iOS, and Android (in beta I think)

    My compose file:

    services:  
      heaper-postgres:  
        image: ghcr.io/janlunge/heaper-postgres:latest  
        container_name: heaper-postgres  
        environment:  
          POSTGRES_USER: $POSTGRES_USER  
          POSTGRES_PASSWORD: $POSTGRES_PASSWORD  
          POSTGRES_DB: $POSTGRES_DB  
        ports:  
          - "5432:5432"  
        volumes:  
          - /path/to/heaper/postgres:/var/lib/postgresql/data  
        networks:  
          - heaper  
        healthcheck:  
          test: ["CMD-SHELL", "pg_isready -U heaper -d heaper || exit 1"]  
          interval: 10s  
          timeout: 5s  
          retries: 5  
          start_period: 20s  
    
      heaper:  
        image: ghcr.io/janlunge/heaper:latest  
        container_name: heaper  
        platform: linux/amd64  
        environment:  
          HOSTNAME: heaper.caruthers.us  
          ENABLE_INTERNAL_POSTGRES: "false"  
          DB_HOST: heaper-postgres:5432  
          DB_USER: $POSTGRES_USER  
          DB_PASS: $POSTGRES_PASSWORD  
          DB_NAME: $POSTGRES_DB  
        ports:  
          - "3000:443"  
          - "4499:80"  
        volumes:  
          - /path/to/heaper/config:/usr/src/app/config  
          - /path/to/heaper/thumbnails:/mnt/thumbnails  
          - /path/to/heaper/storage:/mnt/storage  
        networks:  
          - heaper  
        depends_on:  
          heaper-postgres:  
            condition: service_healthy  
        healthcheck:  
          # Docs show example health probes; adjust host/port if your container differs.  
          test: ["CMD-SHELL", "curl -fsS http://localhost:80/api >/dev/null || exit 1"]  
          interval: 15s  
          timeout: 5s  
          retries: 5  
          start_period: 30s  
    
    networks:  
      heaper:  
        name: heaper  
    

    I have the DB, config, and thumbnails on local NVME, and storage on NFS-mounted NAS. Working fine so far.

    ETA: Correction in compose file.

  • source
  • hideshow 2 child comments
  • [–] 1 point 8 months ago (1 child)

    Does it store uploaded files in plain text on the file system?

  • source
  • parent
  • hideshow 1 child comment
  • [–] [S] 1 point 8 months ago

    From what I can tell, notes are stored in the DB, but can be exported as JSON, or I think markdown. It sure about markdown. I’ve only been able to export JSON, and it didn’t include the image I had embedded in the note. Whatever isn’t a note (images, movies, pdf, doc, etc.) is stored on the file system in a directory structure that files them under heap -> asset checksum. Thumbnails are included there if applicable. In that regard, it kind of forces you to use its folder structure.

  • source
  • parent
  • [–] 3 points 8 months ago

    To each their own but I think I prefer to stick to Nextcloud and just continue to keep things organized the old fashioned way for the most part.

    Though for documents those all get fed to paperless-ngx

  • source
  • [–] 4 points 8 months ago (12 children)

    Postgres? Sorry. If it needs a database, it's probably not for me. Can't be asked to keep another database backed up.

  • source
  • hideshow 12 child comments
  • [–] 5 points 8 months ago (3 children)

    What is your struggle with db backups? Databasus makes it so trivial for me personally.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 8 months ago (2 children)

    The fact that I have to use a more complicated tool than cd.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 8 months ago (7 children)

    almost every self hosted service needs a database. and what "another" database? are you keeping separate postgreses for each service that wants to use it? one of the most important features of postgres is that it as a single database server can hold multiple databases, with permissions and whatnot

  • source
  • parent
  • hideshow 7 child comments
  • [–] 3 points 8 months ago (2 children)

    From previous interactions in this community, it seems all but obvious nowadays, when peoples' experience with sysadmin in average amounts to running scripts running docker in some form.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 8 months ago (1 child)

    just to be clear, are you saying that most beginners just copy paste the example docker compose from the project documentation, and leave it that way?

    I guess that's understandable. we should have more starter resources that explain things like this. how would they know, not everyone goes in with curiosity to look up how certain components are supposed to be ran

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 8 months ago

    Essentially, yes: nowadays you can go much further without basic understanding of what's going on. The ability to fire up magic black boxes that are somewhat functional without any configuration or understanding required is liberating at first, so it's perfectly understandable. I don't think it's a panacea, though.

  • source
  • parent
  • [–] 1 point 8 months ago (3 children)

    Most selfhosting services employ a database in their own docker (separate) container.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 8 months ago (2 children)

    oh, I see what you mean!

    they do that for the sake of providing an example that works instantly. but on the long term it's not a good idea. if you intend to keep using a service, you are better off connecting it to a postgres db that's shared across all services. once you get used to it, you'll do that even for those services that you are just quicly trying out.

    how I do this is I have a separate docker compose that runs a postgres and a mariadb. and these are attached to such a docker network, which is created once with a command, rather than in a compose file. every compose file where the databases are needed, this network is specified as an "external" network. this way containers across separate compose files can communicate.
    my advice is its best to also have this network as "internal" too, which is a weird name but gist is, this network in itself won't provide access to your LAN or the internet, while other networks may still do that if you want.

    basically setup is a simple command like "docker network create something something", and then like 3 lines in each compose file. you would also need to transfer the data from the separate postgreses to a central one, but thats a one time process.

    let me know if you are interested, and I'll help with commands and what you need. I don't mind it either if you only get around to this months later, it's fine! just reply or send a message

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 8 months ago (1 child)

    That's a nice offer. But I'm using nixos containers to top it all off. I'm sure it's possible to have a master-db on the core os and the containers access the central db... but I have hardly any time to do the stuff, I'm reasonably competent in as it is. Managing nixos containers and learning how to coneect the databases for using postgres in the intended way... idk. πŸ˜…

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 8 months ago

    So is this basically just another DAM system (but marketed more to end users/self-hosters?

    There are FOSS DAM systems.

  • source