Bounding of Guest Access Tokens by Nomadic Identity
last edited: Sun, 24 Jun 2018 12:06:05 +0200
Guest Access Token is bound to hub item. I mean, that isn't correct. Because the Guest Access Token is in essence proof of trust towards third parties and therefore is it bound to channel, to Nomadic Identity. What do you think about bounding Guest Access Token by Nomadic Identity?
@Hubzilla Support Forum @Hubzilla Development #GuestAccessTokens #Bounding #NomadicIdentity #GuestAccessToken
@Hubzilla Support Forum @Hubzilla Development #GuestAccessTokens #Bounding #NomadicIdentity #GuestAccessToken
I don't see a problem conceptually with cloning the guest tokens, unless I'm missing something. My guess is that the only thing standing in the way of implementing it are the usual obstacles: motivation and time. The lack of questions about guest tokens on the forum leads me to assume that almost no one uses this feature. If anyone were using the feature, they would probably be asking for improvements to the interface. For example, ideally you would be able to select a file or folder in your cloud files and create/assign a guest access token for the item in a dialog without leaving the page. A custom link should appear that you can easily copy to share. These are not impossible things to create, but I suppose no one wants to spend their time on something they don't think anyone is using.
A custom link should appear that you can easily copy to share.My reflection about bounding of Guest Access Tokens by Nomadic Identity is inspired by the
core pledge, Unique Selling Proposition of Hubzilla - Nomadic Identity, independence of Hubzilla user from availability of particular hubs or clons. I mean, that lack of nomadic token damaged the credibility of core pledge - the Nomadic Identity.
