29 comments
@mado the idea is to make it the backend for my fedi client and anybody could use it as they see fit. Having everything as a file system is a very Plan9 thing @julienxx @mado @mado @julienxx imagine a thread of posts, but instead of manually navigate each post individually using a command and its previous output you can just navigate the structure and get all your data as files. Instead of looking at the whole thing from a distance and extracting a small piece of information you can just "walk into" the whole thing and change your perspective so that you only see what you want @foura my own client http://shithub.us/julienxx/masto9/HEAD/info.html @julienxx To be clear, this is a Mastodon client, not an ActivityPub implementation, yes? @a yes, @driusan is working on a real ActivityPub implementation https://github.com/driusan/fedi9 @julienxx That's a cheery test for a screenshot. But I think three might be a problem with your fs layout: it looks like you're using the an id without any qualifications. I haven't looked into how the mastodon code structures them, but I'm not sure (I doubt?) they're guaranteed to be unique across servers or perhaps even users on the same server. It's a big enough number that you probably won't have any collisions (unless it's timestamp-based?), but it's a theoretical possibility. @driusan good point! As far as I know these ids are specific to my instance hence unique but this might cause issues later on. I only envisioned it to be single user so far. @julienxx but even on a single instance (or user) you're still going to be following accounts on other servers, no? @driusan yes, the ids are local copies of toots with an id specific to my instance I believe. Once federated the toot is copied with a local id I mean |
@julienxx what happens if you dd if=/dev/random of=/mnt/mastodon/