Questions about Auth + Offline

#1

Evening all,

I’ve been looking in to moving from Firebase to either Blockstack or Scuttlebutt for my projects. I’m drawn to dApp technology because the guarantee of privacy and data ownership align with the values of my company.

So far Blockstack’s documentation is leaps and bounds above Scuttlebutt’s, but I have one outstanding question that I’m unable to find an answer for either in the forums or in the docs:

What’s the story for offline support?

My current thinking for offline storage is to default to storing files on the device and then synchronize with a Gaia hub when the user comes back online.

But I have no idea how identity will work.
Can a user login be cached indefinitely?
If the user is offline and they want to log in is the only option to continue in an unauthenticated mode until they come back online?

This is the only thing holding me back at this point.
Any insight would be greatly appreciated :slight_smile:

Thanks in advanced.

1 Like
#2

once the blockstack login is over, you can persist the results of fetchUserData() to some secret storage for as long as you like. It would be up to you to determine and execute the sync strategy with blockstack for some or all or your app state. I’ve tried and failed to get multiple storage targets for off-the-shelf redux-persist. Therefore I use redux-persist with local storage, then manually overwrite blockstack when certain parts of local state changes. If the manual overwrite fails until the user logs in, then it’s still persisted locally. It’s getting complicated, so I hope to figure out multiple storage targets. https://github.com/colealbon/cafe-society

2 Likes
#3

Awesome, thanks for the detailed answer @colealbon

I have enough information to move forward here. Thanks!

To your second point, I can definitely see offline sync getting hairy with redux. Have you checked out mobx state tree? It’s a great state management solution (the best outside of relay, IMO). Synchronizing only certain portions of the state would be trivial with that tool.

#4

I’ll check it out. Meanwhile I forgot to mention you should endeavor to set yourself up to use both blockstack and scuttlebutt. I don’t think blockstack has much in the way of messaging.

2 Likes
#5

Combining both is an interesting notion.

Scuttlebutt brings a lot to the table with the way that it’s built around an event queue. It leads to a great architecture. That being said, my biggest reservation about SSB is its longevity.

I love the principals behind it (Staltz’ talk is incredibly compelling) but the documentation has been lacking for a while and that doesn’t give me the same kind of confidence Blockstack does.

Have you leveraged SSB in any projects yet?

#6

I’m not personally familiar with Scuttlebutt, but I’d be very curious to hear either of how you could see us extending Blockstack with messaging functionality. What use cases do you have in mind? And is there anything in particular from Scuttlebutt you could see us supporting as well?

#7

I prefer to use scuttlebutt for decentralized git hosting (still waiting for netlify hosting to support deployment from git-ssb). Otherwise I agree there are questions about scuttlebutt being a going concern.

@markmhendrickson I’m not sure blockstack needs to have messaging but it might be a nice convenience to developers. Just as users can have access to one or more Self Sovereign Identity providers in an app (ie: blockstack, uport), I’d like to give my users access to one or more messaging systems (gundb, scuttlebutt, “blockstack chat” etc). This would be used for setting up multisig, voting, asteroids, or anything that requires multiple back and forth steps.

1 Like