locking between 2 browser tabs

[pgte]

• Version: latest
• Platform: browser
• Subsystem: repo

Type: question

Severity: Medium

Description:

In order to prevent opening the same IPFS node on two different browser tabs, I need to acquire some type of lock. By what I understand, locking in the browser is done in memory, preventing cross-tab access. Is there any way to solve this using js-ipfs?

Steps to reproduce the error:

Not applicable

[dignifiedquire]

you could use cookies to do per domain locks

…

On 16. Oct 2017, 10:33 +0200, Pedro Teixeira ***@***.***>, wrote: • Version: latest • Platform: browser • Subsystem: repo Type: question Severity: Medium Description: In order to prevent opening the same IPFS node on two different browser tabs, I need to acquire some type of lock. By what I understand, locking in the browser is done in memory, preventing cross-tab access. Is there any way to solve this using js-ipfs? Steps to reproduce the error: Not applicable — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[pgte]

My question was more if js-ipfs allows this somehow, and if it doesn't, does it plan to?

(My opinion is that locking to ensure the same IFPS peerId is not shared between tabs should be a core feature.)

[dignifiedquire]

Okay, then I am not sure what you are asking, ipfs-repo does locking so you can't reuse the same repo if both instances try to use the same indexddb entry. Are you asking for an exposed api to do locking in user land, or are suggesting js-ipfs should do more locking out of the box?

[pgte]

I guess I'm asking several things:

• Locking should be done in a shared medium, so the locking can propagate across tabs.
• Locking should be exposed via an API so that apps can verify whether the lock exists and whether they can acquire it.

Makes sense?

[daviddias]

@pgte is there a way to share an object across multiple tabs? That way js-ipfs would check if there is another node on start and just use that one.

[pgte]

@diasdavid AFAIK, you can only pass messages (probably using localStorage), which means that some locking protocol would have to be built on top of this..

I think that the main problem to solve here is detecting that the lock owner tab is dead. This could be somehow accomplished by the owner putting a unique identifier in local storage that will enable other nodes to verify if the owner tab is alive or not.

Another option is to have temporary locks (5 seconds, for instance), which have to be constantly renewed.

Having said this, if two or more nodes boot up concurrently, there would need to be a way to guarantee that one and only of them wins, which I believe can only be accomplished with a consensus protocol.. I think we cannot escape this, but I may be wrong..

[daviddias]

Let's have a session on this during the dev meetings. It is a big question in general, "What to recommend users do when you have multiple tabs of the same domain, web workers, service workers and so on. Who handles the repo and how can we make sure not to be too restrictive (i.e. lock everything) but at the same time not let race conditions or concurrency problems happen"

This is relevant for the Web Browsers work (@lidel), the GUI work (@olizilla), MFS (@achingbrain #1360), the DApps work (@pgte @satazor) and of course for all the js-ipfs users (@alanshaw @hugomrdias).

@alanshaw, @achingbrain, @hugomrdias can I kindly ask you to propose a session around this topic for ipfs/developer-meetings?

[alanshaw]

ipfs-inactive/developer-meetings#19

[hugomrdias]

@Gozala can you have a look at this issue

[achingbrain]

js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide.

If this is still an issue I would recommend opening an issue on the Helia repo.