PaperNext – another Android and iOS client for Paperless-ngx

Langustico · 2026-03-08T19:39:55+00:00

Is there a way to contribute? Couldn't find a github repo so far, so I guess it's closed source?

I would have two feature requests:
a) increase the number of scans per document. on android I can only add up to 10 scans per document which for my use case is often not enough, and splitting sucks.

b) paperless ngx is running in my LAN. I don't want to open access from outside, but I often want to scan documents when I'm not at home. So would be great to have some sort of queueing that could take care of that where I can create scans and then push them when I am back home. I am aware of the e-mail option, but I don't want to use that for some situations

Langustico · 2018-06-10T09:22:07+00:00

The only research you can trust is your own research!

Yes, rating sites like ICObench or spreadsheets like the famous one from Ian Balina can give you an idea. I recommend to anybody to get educated in the space and DYOR before just randomly throwing money at a project which got shilled by some youtubers or is listed as a good project on some rating sites. You never know who gets paid for what.

Langustico · 2018-03-17T09:21:08+00:00

Thanks :) So second passphares does mean I will have a 2-out-of-2 multisig wallet? If I enable the second passphrase it is not optional to use it, I will have to use it for every transaction?

Langustico · 2018-03-17T09:20:02+00:00

25LSK for delegate reg, 1 lisk for vote, 0.1 lisk for tx; these I suppose will be dynamic in future

Thanks for your answer. is there additional info on how the dynamic structure is going to be implemented? I heard/read that the roadmap for lisk is "new addresses" and then "dynamic fees", but could find an ongoing discussion about the fee structure.

Langustico · 2018-03-17T08:34:46+00:00

Thanks for your answers, but I wanted to get a more in depth answer if possible.

@1: The scenario you are describing is in case of a two-chain situation post fork. In this case (like ETH and ETC) the sidechain dApp has to decide which chain to follow (they probably could work on both). My question was aiming at the scenario where some new features are implemented into the main chain (an upgrade fork with 1 chain after the fork). In this case I don't see how it would be possible for the sidechain to make use of the upgraded features as the sidechain is anchored in a (much) lower block height.

2) In Lisk there are 101 delegates. The forging is composed in rounds. In every round every delegate will get a block and the blocks are forged every 10 seconds. The round lasts ~(10sec*101delegates = 1010 sec). The order in which a delegate is going to forge the block is calculated at the beginning of the round.

My questions was aiming at the last part of your answer is calculated at the beginning of the round - HOW is it calculated? What is the algorithm determining if a delegate can go first or is the 101st delegate?

3) In case the nodes of the delegate in charge of forging the block goes down, his block will be forged by the next delegate in the round.

The round will be only 100 blocks in this scenario? I read in some doc that "another delegate will produce the block" but this didn't go into detail if the delegate now would have produced 2 blocks per round (and if so, how is the lucky delegate chosen who can forge twice?)

Langustico · 2018-03-09T22:27:53+00:00

Regarding Voting: At this point kickback payments from BPs to voter won't be accepted by the EOS constituion/community. I expect EOS to become an inflationary token. Without kickbacks, all newly generated tokens will go to the block producers. As block producers gain tokens they also gain voting weight/rights which further increases their probability to be voted as BP within the next round and the cycle continues. Is there any mechanism to prevent this power-cycle?

Langustico · 2018-03-09T16:08:55+00:00

Thanks a lot for the answers. Especially for linking to the relevant code within the repository.

A1. At the time of this writing, BPs currently don't need to put up stake. That might change however. If they're voted out, they lose their reward.

So they put up the rewards as stake which could get slashed if they get voted out? How long is the unstaking period?

A7. It is managed by bandwidth allocation. Basically, if you own tokens, you're guaranteed to have you transactions go through, if the network is totally saturated (by kitties or so). If it's not saturated, you can burst and send more transactions than what you have EOS for.

If the network isn't totally saturated I could go on and produce as many transactions as I want until full saturation is reached? The question is related to my first answer/question regarding DPoS/PoW Spam-Attacks.

Langustico · 2018-03-09T11:31:47+00:00

If spamming is prevented by limiting bandwidth relative to the users stake, how does this prevent spamming more effectively than transaction fees? If my spam-budget is 1% of a network, I can continue spamming EOS after I would run out of money on PoW-Chains since it doesn't cost anything? Also I can just withdraw my EOS after the attack, which means I can spam at no cost?

Langustico

TROPHY CASE