Simeon Vincent

I’m not sure why, but for some reason this morning it occurred to me that I could probably use Shortcuts on macOS to improve my day-to-day workflow. Often when poking around in Finder I want to open a given directory in Visual Studio Code (VSC). My normal workflow is:

1. Cmd+Tab over VSC
2. Hit Cmd+Shift+N to create a new window
3. Cmd+Tab back to the Finder window
4. Drag the directory onto the new VSC window

This works well enough, but one glaring problem with this workflow: I’m lazy.

I’d love to be able to just right-click the directory in Finder and open it directly in VS Code. I’ve used Automator to set this up in the past, but it was more awkward than I’d like. Also, I lost that automation one or two laptop migrations ago, so I couldn’t even use it if I wanted to.

Turns out this is pretty easy to do in Shortcuts … if you know what you’re doing. I don’t, so I fumbled around for a while. So, here’s the tutorial I wish I had 20 minutes ago.

1. Open Shortcuts.

2. Click the “Quick Actions” category in the left sidebar.

   Note: This isn’t strictly necessary, it just helps make setting up the shortcut input a little faster

3. Click the + icon in the toolbar to create a new shortcut.

   

4. Change the input type from “Images and 18 more” to “Files and Folders”.

   

5. Click “Quick actions” to choose what kind of actions can invoke this shortcut. In this case, I only wanted to use the shortcut inside Finder.

   

6. Under “If there’s no input”, change this value to “Stop and respond”.

   

   Note: This will prevent the shortcut from doing anything if it was invoked without the right kind of input.

7. Next, switch the right view back to the Action Library, search for “Run Shell Script”, and either double-click it or drag it below the input box we just configured.

   

8. Change the “Input” dropdown to “Shortcut Input” and the “Pass Input” dropdown to “as arguments”.

   

9. Change the shell script from echo "Hello World" to code "$1".

   

   Note: $1 refers to the first argument passed to the shell script. We surround it with quotes in order to make sure paths that contain spaces work as expected.

10. Let’s warp this up by giving the shortcut an icon and name. Change the name by clicking on “Run shell script” in the title and typing the new title. Change the icon by clicking the icon in the title bar and selecting the icon and color you want to use. I went with “circled right arrow” in Blue.

    

And with that, you should now be able to right-click on a folder in Finder, open Quick Actions, and select “Open in VSC”. Happy shortcutting ;)

I’m not sure why, but for some reason this morning it occurred to me that I could probably use Shortcuts on macOS to improve my day-to-day workflow. Often when poking around in Finder I want to open a given directory in Visual Studio Code (VSC). My normal workflow to do this is:

1. Cmd+Tab over VSC
2. Hit Cmd+Shift+N to create a new window
3. Cmd+Tab back to the Finder window
4. Drag the directory onto the new VSC window

This works well enough, but one glaring problem with this workflow: I’m lazy.

I’d love to be able to just right-click the directory in Finder and open it directly in VS Code. I’ve used Automator to set this up in the past, but it was more awkward than I’d like. Also, I lost that automation one or two laptop migrations ago, so I couldn’t even use it if I wanted to.

Turns out this is pretty easy to do in Shortcuts … if you know what you’re doing. I don’t, so I fumbled around for a while. So, here’s the tutorial I wish I had 20 minutes ago.

1. Open Shortcuts.

2. Click the “Quick Actions” category in the left sidebar.

   Note: This isn’t strictly necessary, it just helps make setting up the shortcut input a little faster

3. Click the + icon in the toolbar to create a new shortcut.
   

4. Change the input type from “Images and 18 more” to “Files and Folders”.
   

5. Click “Quick actions” to choose what kind of actions can invoke this shortcut. In this case, I only wanted to use the shortcut inside Finder.
   

6. Under “If there’s no input”, change this value to “Stop and respond”.
   

   Note: This will prevent the shortcut from doing anything if it was invoked without the right kind of input.

7. Next, switch the right view back to the Action Library, search for “Run Shell Script”, and either double-click it or drag it below the input box we just configured.
   

8. Change the “Input” dropdown to “Shortcut Input” and the “Pass Input” dropdown to “as arguments”.
   

9. Change the shell script from echo "Hello World" to code "$1".
   

   Note: $1 refers to the first argument passed to the shell script. We surround it with quotes in order to make sure paths that contain spaces work as expected.

10. Let’s warp this up by giving the shortcut an icon and name. Change the name by clicking on “Run shell script” in the title and typing the new title. Change the icon by clicking the icon in the title bar and selecting the icon and color you want to use. I went with “circled right arrow” in Blue.
    

And with that, you should now be able to right-click on a folder in Finder, open Quick Actions, and select “Open in VSC”. Happy shortcutting ;)

Another few months have passed and the Chrome team has published another set of updates to the Chrome Web Store’s (CWS’s) Program Policies. Typically the Chrome team would announce this kind of update with a blog post as well as an email to developers, this time they only sent out the developer email (reposted publicly by Stefan Van Damme). They probably skipped the blog post this time because of the small scale of the update, both in lines of text and impact.

In this post I’ll be walking through what changed, thinking out loud about likely motivations, and sprinkling in additional context about policies and the broader ecosystem.

Quality Guidelines

This is the only section of the policy text that was updated. Before this update, the Quality Guidelines were a little weird in that they only had a single top level bullet. Well, now there are two!

(2) When designing an extension, it’s important to ensure it functions as a helpful companion to users' browsing experiences by providing complementary functionality. If utilizing a persistent user interface, extensions should actively enhance the user’s current task while causing minimal distractions. Some common violations include:

(2.1) Side panel extensions which hijack a user’s browsing or search experience.

(2.2) Extensions with the primary purpose of serving ads.

This change was almost certainly inspired by the introduction of the Side Panel API (announcement post) and it’s likely abuse vectors. (A few hours later…) Turns out Oliver, a Chrome Extensions DevRel Engineer, basically said as much in this post:

The context was the launch of the Side Panel API … the goal was just to have some language in place to make it clear that similar policies to our existing ones (single purpose, not providing particularly distracting experiences) also apply to the side panel"

For a quick recap, Chrome’s side panel is essentially a separate web page that is attached to the side of your browser window. Since the side panel is persistent, it has a lot of potential to augment and enhance the user’s browsing experience, but with great power etc.

A persistent UI surface virtually guarantees that not-so-great actors will try to crap up the user experience. As such, this new policy text is almost certainly aiming to both steer developers away from abusive patterns and to arm reviewers with tools to take action against those poor user experiences.

2.1 is worth quickly touching on because browser hijacking is a common problem in the extension ecosystem and is a significant source of confusion/frustration for users. (See my last blog post for another related discussion.) I’m honestly a little surprised to see it mentioned here as other policies also cover search hijacking, but, admittedly, not as directly.

As a brief reminder, if you want to expose a generic search box in your extension, you must respect the user’s preferences by using chrome.search.query() in Chromium (or browser.search.search() in Firefox) to execute a search using the currently selected default search provider.

2.2 is interesting to me because as it explicitly prohibits extensions with the single purpose of displaying ads. This may not be common knowledge, but to the best of my knowledge this used to be an acceptable single purpose. Now it’s explicitly prohibited. If nothing else it’s worth acknowledging the shift here.

I don’t think I ever encountered an extension with the sole purpose of injecting a bunch of ads on a page. Well, at least if you don’t count extensions that inject referral links on everything they can. Don’t do that. It used to be a decently effective way to get on the wrong side of a malware verdict for “[interfering] with the operation of the networks, servers, or other infrastructure of … any third-parties” (source).

That may sound harsh, but the problem is that when an extension clobbers existing referral links on a site, they effectively steal the referral traffic created by that site. While referral hijacking and content blocking both interfere with a website’s revenue streams, there’s a critical difference in the incentives. Content blocking has security/privacy benefits for the user and monetize through subscriptions or donations. Referral hijacking doesn’t improve user security (arguably it actually exposes more information via referrals) and every referral link directly benefits the extension’s developer.

Still, it was very easy for a well-meaning but overzealous developer to get caught on the wrong side of referral hijacking enforcement. Before this, the malware policy was the best match to take action on referral hijacking, but malware verdicts cannot be appealed and Google will not share details about the nature of the violation the developer.

Now, I don’t know if this is what Chrome policy folks had in mind, but that this new language might give reviewers a way to notify developers that they’ve crossed the line on ads without having to go straight to a malware verdict. Time will tell how this plays out.

Best Practices and Guidelines

This page has been updated with a few new bullets that highlight a couple of things that often trip developers up. IMO it’s a good set of changes all around.

(1) Research and understand the Chrome Web Store policies. Before developing a Chrome extension, it is important to review the Chrome Web Store Developer Program Policies and ensure your extension complies with all guidelines and requirements.

I think it makes senes to call this out at the top of the list. IMO policy compliance is an under-appreciated and often overlooked aspect of publishing an extension on CWS.

CWS Developer Policies aren’t meant to make developer’s lives harder. For the most part, they are just putting up guard rails in order to protect users. I’ve seen too many extensions that disregard user privacy, products built on the gray areas of policy, and extension developers that are genuinely surprised when they get hit for what seem to me to be obvious policy violations. CWS policies serve as a minimum bar that says “yeah, maybe you shouldn’t be doing that.”

Shameless plug: if you need help with navigating CWS policy compliance or navigating a takedown, I can help. Use the contact link on incremental.software to learn more.

(4) Developers must strictly adhere to strict guidelines regarding the collection, use, and disclosure of user data, and must obtain user consent for any data collection or usage. Apps that access sensitive user data such as financial information, health information, or personal information must comply with additional policies and guidelines.

This is a great addition. Users are increasingly aware of and uncomfortable with software data collection practices. Data collection is also a very common cause of submission rejections and extension takedowns.

Developers stumble around data collection due (in part) to the curse of knowledge. Often extension developers understand what data they’re accessing, what tradeoffs they’re making around privacy and security, why data collection feels appropriate for their use case, and ultimately that they are just good folks trying hard to make something their users will enjoy. In these situations, the problem is often that the developer forgets to communicate these considerations to end users (and by extension reviewers).

Beyond that, users and reviewers aren’t just worried about how the extension might use their data, they’re also worried about what might happen if the extension’s supply chain is compromised or it’s database gets dumped. Developers have a tendency to focus on happy paths and forget to consider how another party might (say a hacker or a new owner) abuse or misuse the data they’ve collected.

Speaking of which, I strongly encourage all extension developers to be extremely cautious of unsolicited emails about extension monetization schemes. I’ve recently written more about this, but as a short summary they want you to add a little JS to your extension so they can harvest your user’s data (see also data broker). This practice is forbidden by CWS policy and will very likely get your extension flagged as malware and there’s no coming back from that. Don’t be the pawn in someone else’s game.

(10) Chrome Web Store policies are subject to change. Google may update the policies at any time, and developers are responsible for keeping up-to-date with any changes and complying with the updated policies. Updates to our policies will be announced via email to the address listed in your developer account.

This new item appears as the final entry in the best practice list and IMO serves as a nice end-cap.

Developers may not realize it, but CWS policies are regularly updated in response to the evolutions of browser extension ecosystem and broader software landscape. User expectations are changing, new threats emerge, active exploits and abuse campaigns are refined, legal requirements are shifting, the API surface evolves, and at the end of the day we’re all just trying to ship software.

I’m also trying to do what I can to help here; I wrote this post with the hope that it will help make the browser extension policy compliance process a little more explicable. If you have any feedback on this post, you can reach me on Mastodon at @dotproto@toot.cafe or use Mastodon to comment directly on this post.

This post is based on a comment I shared on the chromium-extensions group.

It’s a frustratingly frequent experience for extension developers: you’re going through your customer feedback sent to your contact email address (a CWS requirement) and you come across something like this:

I’m reaching out to you concerning the potential revenue generation from your Chrome Extension, . We are keen on offering our premium product, Bing Hosted Feed, which is a high-quality search solution.

This represents an excellent chance to incorporate a search feature into your Chrome extension, thereby monetizing your users' search activities. With this integration, you stand to earn up to $500 per month for every 1,000 users, paving the way for an extra passive income stream from your extension.

Even if your extension currently lacks a search function, there’s no cause for concern. We are fully prepared to guide you through a straightforward update process to incorporate the search function. This update is fully compliant with Google Chrome store’s guidelines, and should you find it unsatisfactory, you’re always free to revert the changes at any point.

I don’t fault anyone for being tempted by this kind of offer; it’s hard not to be intrigued by solid money in exchange for a seemingly minor integration. But if something seems too good to be true, it probably is. Despite their claims, I’d bet dollars to doughnuts that what they’re doing doesn’t comply with CWS policy. Worse, these services may well end up getting your extension flagged as malware.

Let’s talk about what these kinds of monetization schemes typically ask of developers, look at some relevant Chrome Web Store policies, and see why integrating with them will likely land you in hot water.

What they want

The people behind these emails want to replace the user’s search engine with something that pays them for that traffic.

Why? Because search is very valuable. While it’s hard to find solid numbers on exactly how valuable, Philippe Ockenden, Microsoft’s Corporate Vice President of Finance, said on an investor call that “For every 1 point of share gain in the search advertising market, it’s a $2 billion revenue opportunity for our advertising business.” That’s big money.

More concretely, the people behind these emails typically want the integrating extension to change the user’s default search provider using Settings Overrides. In some cases, though, they may ask developers to expose a search box in the extension’s UI or on websites. A search box would usually be integrated by adding some pre-defined HTML and their JavaScript library into the target page.

They don’t mention this part, but they’re also looking to minimize their own risk at your expense. They know that CWS can only take action against an extension and its developer. So, if the worst happens and the code they asked you to integrate is flagged for malware, your extension will be taken down and your account will be suspended.

Chrome Web Store policies

Roughly 7 months ago Google revamped the CWS Developer Policies around three principals: be safe, be honest, be useful. These simple statements get to the core of what the policies aim to accomplish: enhance the user’s web browsing experience without deception, fraud, mishandling of data, or disregard for the user’s wishes.

I mention that here because search monetization, by its very nature, can be considered a form of browser hijacking. From Wikipedia:

Browser hijacking is a form of unwanted software that modifies a web browser’s settings without a user’s permission, to inject unwanted advertising into the user’s browser. A browser hijacker may replace the existing home page, error page, or search engine with its own.^[1] These are generally used to force hits to a particular website, increasing its advertising revenue.

Let’s walk through some specific policies in order to see how search monetization may put your extension at risk.

Single purpose policy

CWS has long had a “single purpose policy” (SPP) that essentially requires each extension have one well-defined raison d’être. Generally speaking, this means that all of the features an extension exposes must be part of a unifying theme. This policy is currently captured in the Quality Guidelines policies.

One area where SPP enforcement is stricter than average, though, is search. For the purposes of CWS review, changing a user’s default search provider is considered a distinct purpose. In other words, if the search monetization service instructs you to declare a search provider in your extension’s manifest with "is_default": true, that integration is basically guaranteed to violate this policy.

API use

The API Use policies require that developers “use existing Chrome APIs for their designated use case. Use of any other method, for which an API exists, would be considered a violation.” If the extension is exposing a general purpose search box, the extension must use chrome.search.query() (or browser.search.search() in Firefox) to perform the search.

Policies aimed at protecting user privacy

Integrating a search monetization service will likely violate a couple of the policies grouped under Protecting User Privacy.

The Limited Use policies requires that user data only be accessed/collected for purposes directly tied to the extension’s purpose. Any data collected must be limited “to the extent required for a user-facing feature described prominently in the Product’s Chrome Web Store page and in the Product’s user interface.”

Similarly, the Disclosure Requirements policies state that extensions must disclose the data they handle (collect, use, or share) and, if necessary, get informed user consent for that handling.

While one might argue that the extension isn’t collecting search data, it directly facilitates sending user data to a 3rd party service which may collect the user’s data for advertising purposes. That data would not have been collected but for the fact that the user had the extension installed. At best, that’s aiding and abetting – not a great defense to use when trying to get back into good standing.

Finally, the Misleading or Unexpected Behavior policies clearly state that extensions must not “misrepresent the functionality of your product or include non-obvious functionality that doesn’t serve the primary purpose of the product.”

Let’s make this a bit more concrete with an example. Say you had an extension that exposed a search field that looked and mostly behaved like a standard search box in your browser. Now say that when you executed a search using that box, the results page was on a website you weren’t used to seeing. I think it would be fair to say that the search box didn’t behave as expected.

A compliant example

At the moment, I can only imagine one situation where it would be appropriate for an extension to execute a search without using the default search provider: if the extension is exposing specialized search capabilities related to its single purpose.

For example, let’s say there is an extension designed to help users find, collect, reference, and site academic papers. This extension could expose a search box that lets users search through the academic databases and industry journals they are signed into. This type of search is directly related to the extension’s primary purpose, makes sense in context, respects the user’s preferences, and does not introduce new privacy concerns.

Wrap up

Trying to monetize an extension by sending search traffic to a non-standard search provider is, at best, risky business. Browser hijacking is a serious threat to users and anything that looks like it has a very real risk of being classified as malware.

My advice: steer clear of offers to monetize your extension via search revenue sharing.

Chrome Web Store policy allows ads in extensions, but can Google’s ad products be used in browser extensions? Let’s dig through some policy docs to find out.

Someone posted a question in the chromium-extensions Google Group a couple weeks ago asking whether they were allowed to use Google Ads in browser extensions. When I last looked into this I worked on the Chrome Extensions team and the short answer was “you can’t use Google’s ad services, but you can use other services if the policies of those services allow it.”

Since then my relationship with this question has changed. Google and I have parted ways, I began building my extension dev consultancy, and I’m looking for other revenue streams to diversify my income. In other words, this question is more relevant to me than ever before. So, let’s see if we can’t get a hard answer.

In this post we’ll be taking a look at a few different Google policy sites and seeing what (if anything) they have to say about browser extensions.

Chrome Web Store policies

Let’s start by reviewing the Chrome Web Store’s Program Policies. The Ads policies basically says that extensions can display ads as long as they conform to some specific requirements. One of those requirements immediately raises a red flag when it comes to inegrating Google ads.

3. Currently, AdSense may not be used to serve ads in Products, per AdSense policies.

If you do a web search for a set of terms like chrome extension google ads you’ll probably see posts on StackOverflow where people quote this and throw up their hands. But this in itself isn’t a prohibition; it’s an attempt to summarize someone else’s prohibition. Let’s see if we can’t track down a primary source for this.

AdSense Program policies

Following AdSense Policies link takes us to the AdSense Program policies page page. The first thing I do when trying to quickly grok something like this is search the page for relevant terms. The word “extension” doesn’t appear anywhere on the this page and the word “browser” only appears twice. Looks like i’ll actually have to dig into the text and try to divine the spirit of their meaning.

I’ll spare you the blow-by-blow analysis and I’ll summarize most of this page is just absolutely hammering home that Google really don’t want publishers (the site showing ads) to do an ad fraud. Beyond that, there are only a couple of passages related to the question we’re trying to answer.

Ad placement

Publishers are encouraged to experiment with a variety of placements and ad formats. However, AdSense code may not be placed in inappropriate places such as pop-ups, emails or software. Publishers must also adhere to the policies for each product used. Please see our ad placement policies article for more information.

The second sentence in this passage describes “software” as an inappropriate place to display AdSense ads. That’s a pretty broad category, but writ large they appear to be saying that AdSense may only be used to monetize websites. To drive that point home they continue:

Google ads, search boxes or search results may not be:

• Integrated into a software application (does not apply to AdMob) of any kind, including toolbars.

The use of “including toolbars” here is interesting. As previously mentioned, this document doesn’t use the word “extension,” so this (dated) reference to Internet Explorer toolbars is about as close as we’ll get and their stance seems clear.

But to drive the point home, let’s follow that “ad placement policies” link from the first quotation and see what they have to say.

Ads in a software application

Publishers are not permitted to distribute Google ads or AdSense for search boxes through software applications including, but not limited to toolbars, browser extensions, and desktop applications. AdSense code may only be implemented on web-based pages and approved WebView technologies.

That’s about as explicit a prohibition as I could imagine. But, I should note that the first paragraph of page explicitly identifies the page as covering “Adsense ad placement policies.” That’s critical because didn’t shut the door on Google Ads in extensions: there’s an AdMob-shaped escape hatch we can look into.

AdMob’s Behavioral policies

AdMob is governed by the AdSense program policies, but with some additional exceptions and guidance for this specific product. On a side note, I don’t know why they decided to name the page that provides that guidance “Behavioral policies” rather than something like “AdMob product policies” but, well, there it is.

Exceptions to AdSense policie

In principle, all AdMob publishers must follow our online program policies, however there are certain policies that differ between AdSense and AdMob. Please see the exceptions below.

“Ad placement” presented a problem in the AdSense policies, so what does AdMob policy say?

Ad placement

Publishers are encouraged to experiment with a variety of placements and ad formats, but must comply with the Google Publisher Policies. Please also review our implementation guidance.

AdSense Implementation guidance

The Implementation guidance page doesn’t contain any explicit mention of extensions/toolbars or other language similar to what we saw before about not allowing ads in certain types of software. It does, however, contain the following guidance:

Integrate the latest SDK

It’s important to always stay updated with the latest SDK (for Android, iOS), which will give you access to the latest ad formats, features, and bug fixes.

This passage is interesting because it implies that SDK integration is important without explicitly saying it’s required.

So, is it required? Let’s see what the AdSesne and AdMob policy pages have to say. The AdMob policy page references the this SDK and the fact that it’s used to serve personalized ads:

Personalized advertising

Google may use the advertising ID from the device on which the ad is serving to generate interests and demographics (for example, ‘sports enthusiasts’). Interests, demographics, and other data may be used to serve better targeted ads to the user. Additionally, your app’s privacy policy may need to be updated to reflect the use of personalized advertising (formerly known as interest-based advertising) served via the Google Mobile Ads SDK.

Again, this does not explicitly say that the SDK must be used, but that fact is heavily implied.

The smoking gun appears on the AdSense Program policies page in the “Technical requirements for web content viewing frames for apps” section.

1. WebView API for Ads
   App developers are encouraged to integrate the WebView API for Ads to register WebView instances (Android: WebView, iOS: WKWebView) with Google Mobile Ads SDK.

   […]

   AdMob and Ad Manager in-app ads may be shown in an app next to a WebView as long as the Google Mobile Ads SDK is in use and the publisher is compliant with all other relevant program policies and guidelines.

I read this section as saying that developers MUST use the Google Mobile Ads SDK to manage AdMob and Ad Manager ads. There’s only one problem: Google doesn’t provide a JavaScript SDK. They have Android, iOS, and Flutter SDKs.

Well … shucks.

Wrap up

We ran through a bunch of different Google Ads policy documents to try to figure out whether or not browser extension developers can integrate Google Ads in their products. Here’s what we found:

• AdSense
  • Forbidden from appearing in browser extensions (source).
• AdMob
  • Policy does not forbid these ads from appearing in extensions.
  • Ads must be handled by the Google Mobile Ads SDK.
  • There is no JavaScript version of this SDK.

Given all that, it looks like there’s currently no policy-compliant way to display Google Ads in a browser extension. This could change if either (a) Google allowed extensions to use AsSense or (b) Google provided either a WebExtension SDK or a JavaScript SDK.

Came across grepjason.sh/discover/ (via the docs) when looking for more info about how to find people talking about stuff I’m interested in. It’s an overly large bucket, but I’d still very much like to see @burk’s suggestion of a 💻 tagmoji for “Technology/Programming”. As someone specifically interested in the web and web browsers, I’d selfishly like to suggest 🕸 for “Internet/Web”.

Even if it’s not surfaced to other Micro.blog users, I’d love to see a way for a user to tag or otherwise organize their own posts. This omission seems a bit surprising given Micro.blog’s emphasis on users hosting their blogs on their own domains.

Thread

• Previous: Micro.blog thoughts #3: posts >300 characters

Next weird thing, the UX around adding titles is odd. I know posts don’t have a hard 300 character limit. The docs suggest giving your post a title when it’s over 300 characters, but it’s not clear what that looks or feels like. Does only the title appear in the feed? If we jack into Hugo-level customizations can users provide a metadata field for a description and use that instead?

As a new user, it’s odd and surprising to me that the title field doesn’t even appear in the editor UI until the draft post contains at least 300 characters. I just checked for an account level setting to make this setting always appear, but no dice. That might be good fodder for a browser extension.

Thread

• Previous: Micro.blog thoughts #2: Threading
• Next: Micro.blog thoughts #4: Discovery and organization

Re: dotproto.com/2023/02/2…

New stumbling block: threading. There’s no obvious way to link multiple microblog posts together. For the moment I guess I’ll fall back to manually referencing the previous post as I have here, but that’s obviously not ideal.

EDIT: The original approach I used was to add “Re: [LINK TO PREVIOUS POST]” on the first line. I’m replacing that with a manually created “previous” and “next” footer links.

Thread

• Previous: Micro.blog thoughts #1: Am noob, send help
• Next: Micro.blog thoughts #3: posts >300 characters

I’m trying to wrap my head around how to engage with the micro.blog community and I feel like I’m grasping at straws. If you’re already here and active, you probably have a pool of people that you read, but as someone with no existing ties I feel adrift. micro.blog/discover is too limited :/

Thread

• Next: Micro.blog thoughts #2: Threading