We definitely plan to enable effortless transformation of any block into an object, for example, by adding a tag to it or simply by mentioning it in another object 'transclusion'.
We also have plans to develop a simpler local API and a local AI helper that will be able to assist you with import/export tasks in ways you might think of
Thank you for the input! If you're looking for a clean space, you can easily create a new one by clicking on your profile icon in the panel at the bottom. It will contain only a few sets. You can always delete spaces that are no longer needed.
If you need a simple notepad, there are better tools out there. Anytype is more suitable if you're looking to create something like a database or knowledge base, not just a list of notes.
The next year we are working on simplifying the user experience and introducing multiplayer+communication
Yes, we are aware that there is a steep learning curve before you reach the point where you feel it's worthwhile. It's absolutely true that if you need a tool solely for note-taking, Anytype might not be the best option. We envision Anytype as a tool for knowledge management and communication (we're launching multiplayer early next year). One of our biggest internal projects is to simplify the user experience. With each new release
Thanks for the feedback about the screenshots! We'll get that fixed.
The license is somewhat vague. Essentially, it means you can use the software as a tool for your revenue-generating business. You have the option to use it for free if you self-host. Alternatively, you can choose a paid membership in our network, which eliminates the need for you to handle maintenance. The license specifically restricts selling the software to others without ANY coop consent.
I'll try to clarify: For syncing objects (anytype native data structure), we use IPLD in conjunction with our own networking layer. For file synchronization, however, we opt for IPFS without libp2p, since a faster method is necessary to improve the user experience. This strategy ensures our file storage is compatible with the public IPFS network and incentive-based storage networks like Filecoin and Arweave. Additionally, it provides a significantly faster experience for our users now. This approach works much better for cases when you have many small files ( what often the case in pkm and communication).
I wouldn't say it's extremely slow. While benchmarks can be useful, they often don't align with real-world experiences. What exactly are you comparing? Is it just rendering time? Have you considered a user's workflow, which might involve navigating through several pages or objects? In reality, we've attracted many users because they find 'Notion' to be slow, and many appreciate the speed of Anytype. Based on this, I believe it's not fair to give Anytype the same rating as Notion in your diagram. Also, I would assign a higher rating to Bear and Craft; their desktop apps are faster since they are native.
There is significant room for improvement, and we're already steps ahead in this area with our native mobile clients that sync peer-to-peer. Try our Android app and see for yourself. I hope that within the next three years, we'll excel with native desktop applications as well.
The value proposition of Plume looks good; I've left my email.
Hi! If you click on the "More details" button, you'll see the following table[1].
Here's the methodology (also available on the website):
1. Loading time: Fully loads the entire text and ready to scroll.
2. Memory use after load: Memory used by the app after loading the text.
3. Scroll jump: How fast the app scrolls when dragging the scrollbar to a far position.
4. Resize: How fast the app resizes after scrolling to the middle of the text.
5. Select all: How fast the app is at multiple operations: Select all text, cut, paste, undo, redo.
6. Editing: How fast the app is at typing at the middle of the text?
7. Memory use second time: Memory usage after doing all the above operations multiple times.
8. Binary size: Binary size of the app.
9. Cross-platform: Can the app run on Windows, Linux and macOS?
I think these are very fair benchmarks. And objectively speaking, both Bear and Craft didn't perform well (well, Craft couldn't load the text since it has a limit on the amount of paragraphs it can load).
EDIT: Just noticed you signed up! Thanks for that! BTW, I did try Anytype's iOS app and it was very smooth compared to the web/Electron one.
Huh - it was surprising how poorly Bear fares in that benchmark given I use it regularly and find it snappy and responsive. But then I looked closer and saw you were loading War and Peace into it.
I'll let you in on a dirty secret: Most of my documents aren't as long as war and peace. I care a lot more about "normal" document sizes and real world typing latency. Is Anytype actually slow in this case?
My benchmark is largely based on the "Moby Dick Workout"[1] of Jesse Grosjean. I agree with him that ANY text editor should pass these tests. And block editors are first and foremost text editors. I just decided to take it up a notch and do my tests on War and Peace.
Another very crucial point, a good deal of software today is written with no oversight on performance at all, so you end up needing to buy the latest hardware to run apps smoothly. Why would anyone need a M3 Macbook to run a text editor fast??
This is why I used a 2017 Macbook Air in my tests and not the M1 Pro next to it. Efficient software matters for the longevity of hardware.
Yeah thats fair. I have a friend building a personal thought management system, like roam research. Her goal is to store everything she thinks in her life.
In the 8 years or so she's been working on it she's recorded about 100k thoughts. So, 1 million thoughts is probably enough to store everything you think in an entire lifetime. Thats a bit of a grim thought, but its probably about the right performance target for something like that. There's something very calming about knowing that if it performs well with 1M thoughts, its fit for purpose.
Its nice to have benchmarks like that.
For what its worth, I'd recommend explaining all of that with the benchmark explanation. "Measured on a 2017 macbook air with the text of War and Peace". Seeing Bear crash doesn't really tell me enough about whats going on.
> There's something very calming about knowing that if it performs well with 1M thoughts, its fit for purpose.
Exactly. I've been using my note-taking app (of which Plume is built on) since 2014, so I have 4850 notes in total, and it's still rock solid and fast.
Another plus of efficient software is that my 2017 Macbook Air actually loads text ~2x faster than the best competitor (Bike) on a 2021 M1 Pro (with much more performance)
2017 MacBook Air:
Plume: 0.8 seconds
Bike: 3.46 seconds
MacBook M1 Pro:
Plume: 0.3 seconds
Bike: 1.5 seconds
That alone says a lot.
> For what its worth, I'd recommend explaining all of that with the benchmark explanation. "Measured on a 2017 macbook air with the text of War and Peace". Seeing Bear crash doesn't really tell me enough about whats going on.
Thanks for letting me know. Do you have a suggestion for how to convey it better?
> What does vim support inside a block editor means?
Users who care deeply about note taking want don't want to learn a new set of keyboard shortcuts and movements. Apps like Logseq and Obsidian (and many others) either support Vim-style movements out of the box or they're available as a plugin. Same thing with Emacs-style shortcuts and Org mode.
Folks have been using these editors for decades and they want to use their muscle memory everywhere they enter text.
Depending on the user and the use case, the lack of Vim or Emacs support ranges from a minor annoyance to a show-stopper.
If that's what OP meant, then no. Plume will support the basic keyboard shortcuts expected from a text editor, and then some more. My previous note-taking app[1] is already very keyboard oriented, and I intend to do the same with Plume.
EDIT: Just noticed that most of the "Cursor movements" already have equivalent standard keyboard shortcuts in regular text editors.
