Live data from Hacker News

Show HN: Anytype – local-first, P2P knowledge management

anytype.io

21–30 of 83 posts

Re: Show HN: Anytype – local-first, P2P knowledge management

#21

Anytype is extremely slow and a resource hog, similar to its other Electron counterparts, as can be seen on a benchmark I did.[1] I’m developing Plume[1] which has a similar advanced block editor but since it’s built with Qt C++ and QML, is very performant (more so than comparable native apps!). EDIT: Some work in progress: https://imgur.com/a/LwitrHe [1] https://www.get-plume.com/

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.

Re: Show HN: Anytype – local-first, P2P knowledge management

#22

Anytype is extremely slow and a resource hog, similar to its other Electron counterparts, as can be seen on a benchmark I did.[1] I’m developing Plume[1] which has a similar advanced block editor but since it’s built with Qt C++ and QML, is very performant (more so than comparable native apps!). EDIT: Some work in progress: https://imgur.com/a/LwitrHe [1] https://www.get-plume.com/

What sets Anytype apart as a local player is its notion-style databases, and I believe it is unique in that respect. If the outlining experience is good enough (drag/drop, collapse...), I will definitely try Plume for "light/fast" note-taking.

I've decided to depart from the complexity of databases. Instead, Plume is going to be more opinionated and simple. It will support Kanban boards, tables, columns, images and other complex block types, but the data won't be separated into different "databases". Essentially, each note in Plume is a simple markdown/plaintext file.

Drag and drop and collapsible blocks will be supported for sure, so sign up for the wait list and check it out upon its release (:

Re: Show HN: Anytype – local-first, P2P knowledge management

#23
post #21

Anytype is extremely slow and a resource hog, similar to its other Electron counterparts, as can be seen on a benchmark I did.[1] I’m developing Plume[1] which has a similar advanced block editor but since it’s built with Qt C++ and QML, is very performant (more so than comparable native apps!). EDIT: Some work in progress: https://imgur.com/a/LwitrHe [1] https://www.get-plume.com/

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…

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.

[1] https://imgur.com/vEfV7Iq

Re: Show HN: Anytype – local-first, P2P knowledge management

#24
The screenshots seem to disable zooming on mobile. Please don’t do that.

Unfortunately the usage restrictions of the non-open-source licence make it a no-go for me. Can't use it for anything that could potentially facilitate "any transaction of economic value", which removes most of the utility of such an app.

Re: Show HN: Anytype – local-first, P2P knowledge management

#25
post #12

Earlier quoted context omitted.

Thanks for your input. On the p2p topic: Our protocol is p2p and it's already working well in local networks. You can experience the magic yourself: install Anytype in local mode, create a space, and fill it with some data. Open the mobile app and log in with the same phrase, and your data will be synced without any central server, immediately! Isn’t it magical? The network is needed for backups and to solve the clos…

I completely agree with the threat model of "an attacker on your machine can get to the keys" but I'd like to add two security use cases that makes encrypting indexes valuable: 1. Off-the-shelf malware exfiltrates data, as seen in ransom attacks. I'd feel better if the index was encrypted. It's unlikely an attacker would manually spend time trying to find the keys in RAM unless your app became very famous :) 2. Synci…

im not the dev but what you're wanting is completely unreasonable. No note application does this and this would slow down the application without having any additional benefits

Re: Show HN: Anytype – local-first, P2P knowledge management

#26
post #12

I found Anytype a few months ago and thought "wow maybe I can ditch Turtl (I am the creator) and just use this." A few things bugged me about it: - It's a source-available license. - You can't share with others (yet) even though they promote this as a feature. - They call it e2e encrypted, but all your data lives unencrypted on-disk. In other words, it's encrypted in transit but not at rest. Anyone/anything that can…

Thanks for your input. On the p2p topic: Our protocol is p2p and it's already working well in local networks. You can experience the magic yourself: install Anytype in local mode, create a space, and fill it with some data. Open the mobile app and log in with the same phrase, and your data will be synced without any central server, immediately! Isn’t it magical? The network is needed for backups and to solve the clos…

Use GPL so the project can go on longer than the company.

Re: Show HN: Anytype – local-first, P2P knowledge management

#27
post #21

Earlier quoted context omitted.

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…

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…

do you also have vim support? This is crucial for me

Re: Show HN: Anytype – local-first, P2P knowledge management

#28
post #27

Earlier quoted context omitted.

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…

do you also have vim support? This is crucial for me

I'm sorry, I've never used vim. What does vim support inside a block editor means?

Re: Show HN: Anytype – local-first, P2P knowledge management

#29
post #16

As someone who's been active in the IPFS community, it's really exciting to see how Anytype uses content addressing to manage and sync data under the hood ( https://github.com/orgs/anyproto/discussions/15 ). I think the fact that local-first P2P apps cannot be built directly on the web is a shame, some of the building blocks, like WebRTC are there, but browsers still lack some APIs to allow for more bottom-up innovat…

TLDR for others: Anytype is using IPLD (https://ipld.io/), which is a project that came out of IPFS, but Anytype doesn't use IPFS itself (nor libp2p, or multiformats).

Seemingly they felt it was necessary to write their own network layer and more as stable identifiers and logic for merging documents was too complicated to put on top of IPFS:

> We also considered using IPFS, but its approach to content identifiers didn’t meet our use cases. While IPFS could address our requirements for hybrid networking, it uses CID to describe documents, and this CID changes with each modification. However, we need documents to have stable identifiers for linking and other purposes.

> Creating stable identifiers and implementing logic to merge different document states on top of IPFS would be too complex, so we chose a straightforward approach.

Not sure I understand correctly. They found the data model of IPFS not good enough, so they ended up using the data model provided by IPFS in the form of IPLD, but the things they weren't against (the networking layer) were the things they wrote themselves?

Surely I must misunderstand something here.

Re: Show HN: Anytype – local-first, P2P knowledge management

#30
post #25

Earlier quoted context omitted.

I completely agree with the threat model of "an attacker on your machine can get to the keys" but I'd like to add two security use cases that makes encrypting indexes valuable: 1. Off-the-shelf malware exfiltrates data, as seen in ransom attacks. I'd feel better if the index was encrypted. It's unlikely an attacker would manually spend time trying to find the keys in RAM unless your app became very famous :) 2. Synci…

im not the dev but what you're wanting is completely unreasonable. No note application does this and this would slow down the application without having any additional benefits

> No note application does this

Yes, the app Turtl (https://turtlapp.com) does do this and it's not slow at all really. It only decrypts data upon viewing, and immediately re-encrypts when saving data. So this is actually entirely reasonable and entirely doable. The benefits are that malicious applications can't read data just sitting on the hard drive, which removes an entire class of attacks. An encrypted hd doesn't help you when it's unlocked.

Post reply on HN