The 'Follow' button in a third-party app #1798
Replies: 4 comments 1 reply
-
|
Different than above, here's a solution a friend suggested that requires less permissions into the profile drive:
This works well when there's exactly one profile drive per Beaker installation. @pfrazee If there isn't a profile drive, I'm not sure how I can differentiate the user declining to tell the existing installation anything with the user actually not yet having their own copy of the app installed (and I'm worried squeamish users who answer inconsistently will end up with a confusing mess of multiple installations). |
Beta Was this translation helpful? Give feedback.
-
|
And here's a new possible design, @pfrazee which works without there being a profile drive, and riffs a little on Web Intents/Web Activities from ~2010ish. The existing API This idea adds a little to Beaker would keep the user in control of sharing this information with boxes that look something like this: Also on these boxes, a smaller link or button Choose another drive... expands the list to all the user's drives. And a link like More information + on the box could expand to include text like: This page wants to see one of your drives, to read information from it, or make a link to it that contains a message. Choose a drive and click OK to share the address with this page. |
Beta Was this translation helpful? Give feedback.
-
|
More thinking on this, splitting it out into a separate API: Every blog comes with its own feed reader appImagine a Beaker app that is a kind of a feed reader, in that it knows how to retrieve posts in a certain format from around the hyper web, and format them into a feed for you. You can use the feed reader app to read your own posts, posts of blogs you follow, and click from there to new posts and blogs you're reading for the first time. All the while, you're always navigated to and using your own copy of the app. Before you got your own copy of the app, you found out about it when a blogger you know from elsewhere posted a link to her blog on her drive using this app. This link might have the blogger's hyperdrive hash twice, first to navigate Beaker to the blogger's hyperdrive and run the app, and then to tell the app which posts to fetch and display: As you click blog to blog, the view parameter changes, but Beaker stays navigated to the same page. Before you get your own copy of the app, you're using the blogger's, and it works fine just for clicking and reading. Next you want to write your own post, follow this blog, or like something. To do this, you'll install your own copy of the app. Installed on your own hyperdrive, the app will be able to edit files to keep notes of which blogs you're following and which posts you've liked. A week later, you've forgotten about the app entirely, when another creator you know from Twitter tweets a link to his decentralized blog using the app. You click it, and start reading his blog on his installation, which again is read-only. When you click like, your own copy of the app could do it, but first you have to get back there. User experienceThe app determines if it can write to the hyperdrive you're on (which doesn't require a user prompt). If it can't, it shows the visitor a bar at the top that says something like this:
Or, if your Beaker already has a hyperdrive with the app installed, the bar says:
New APITo be able to do this, I'm asking for a new API. The page asks Beaker, "Does this user have any hyperdrives that are tagged This API will enable a flow where it's much easier for new users to get their own copy of the app, and for returning users to find one they may have installed earlier. Altogether, this design (I think) accomplishes the goals I've been describing in earlier comments on this discussion, while also avoiding the pitfalls. |
Beta Was this translation helpful? Give feedback.
-
|
That's a logical idea -- you still have to consider the information being leaked there is nonzero. I'd want to make sure it's not doable by other means first because of that - can we take a look after the 1.0 release? (Which, swear to FSM, is sitting ready and just waiting for my windows code-signing cert to get approved) |
Beta Was this translation helpful? Give feedback.
-
|
Here's the solution we came up with, (to answer the question I posted at the top). Code in my app looks like this: //find an existing installation, or make a new one, returns .driveHash has text or .userDenied true
async function findOrMakeLocalEditableDriveWithThisAppInstalledOnIt() {
try {
var u = await beaker.shell.selectDriveDialog({
title: `You already have ${brand}. Select your ${brand} drive to use it.`,
writable: true,
allowMultiple: false,
tag: brand,
template: shrinkwrapDrive
});
return u ? {driveHash: u} : {userDenied: true};
} catch (e) {
if ((e+"").contains("UserDeniedError")) return {userDenied: true};
else throw new Error("selectDriveDialog rethrow", {e});
}
}Keeping with the goals and ideas described earlier, here's the flow: Once the drive is found or created, the existing installation Beaker is navigated to and that's running this code (someone else's installation that the user can click around as a read-only guest, essentially) redirects to the user's new read+write drive running |
Beta Was this translation helpful? Give feedback.
-
@pfrazee 's Blahbity-blog sample is a design for a social feed app that, while decentralized, still presents an experience users find familiar. Alice and Bob both have their own hyperdrives, and their own copies of the blahbity code. They write posts by creating new markdown files in their hyperdrives. The app assembles a feed for you by querying your hyperdrive and the hyperdrives of users you follow.
What's the best way for a blahbity-like app to install and follow? How can we prevent griefing without resorting to centralization? I'm interested in everyone's thoughts.
To explain in more detail, here's: (1) notes on the common experience users know well from centralized sites and apps; (2) a solution that works right now, but not well, and; (3) one possible alternative, which imagines a new Beaker API.
(1) Notes about the current, common centralized experience on traditional sites and apps
Imagine you're a Google user (browsing the web with Chrome signed into your Gmail). You have other online accounts, but nothing at Twitter. You click a search result into Twitter, and begin reading Elon Musk's feed:
Both the Sign Up and Follow buttons begin a flow that will get you onto Twitter. You can complete this flow without leaving Twitter. Twitter handles the whole process, not needing identity information from Chrome or additional browser permissions from the user.
While Twitter's servers hold everything (all their code and all your data), identity is at least decentralized down to the site--DeviantArt, Wikipedia, and Reddit can each design user identity, access, and permissions however they want to.
(2) Current APIs, but permissions too great
Imagine three Beaker users, each with their own profile hyperdrive:
Having the app means having an index.html file in a folder in your hyperdrive that looks like this:
Alice has this index.html file, which runs Daryl's current code in app.js. Daryl's code builds the whole page from the pageid tag. Settings specific to Alice's use of the app, like her blog's name and description, and the list of people she follows, are in her settings.json in her own hyperdrive. Alice's posts are in .md files alongside these files in the app folder.
Updates: Done this way, Daryl can update the app as easily as Twitter can update twitter.com. (Also: If Daryl updates things in a way Alice or the community doesn't like, she or anyone can copy the program files from Daryl's public hyperdrive to revert a change or modify things further, which you can't do with closed-source, closed-server Twitter. Well, except for that recent hack, of course.)
Install and Follow: Bob finds Alice's posts, reading them with Beaker navigated to index.html in Alice's hyperdrive. Bob wants to join the app, to follow Alice and maybe later write a post or two of his own. When Bob presses Follow, a bunch of stuff happens:
It's great that Alice keeps her own data, and visitors read Alice's posts on Alice's hyperdrive. Users see a familiar, working Follow button on the page beside Alice's posts.
But, this design obviously depends on everyone being nice. Daryl or Alice can mess up Bob's profile drive.
(3) Possible new API
Alice and Bob both have Daryl's app installed, and trust Daryl with code and updates. (Another app maintainer, Edgar, can fork Daryl's app, but there will be more A and B users than D and E users, so let's assume we can trust D and E users.) Bob wants to follow Alice, but can't trust the code beneath her Follow button. After all, Bob is clicking user to user, hyperdrive to hyperdrive, and can't trust everyone he's reading.
Could Alice's Follow button have Beaker ask Bob if it's ok for Alice's page to deliver a short JSON message to Bob's app? This message would say, essentially, "follow Alice at her drive with this hash". Bob's code (not Alice's) would run, receiving the message, and edit Bob's settings.json. Additionally:
(4) Your or an existing idea/solution, as I'm just staring to think about this
Writing this and then remembering Webmention, I realize this may be a similar problem with existing solutions devised for the traditional web that could be implemented or modified for decentralized life in Beaker.
So my question is, what is (or could be) the right way to do this?
Beta Was this translation helpful? Give feedback.
All reactions