Decentralized social networking with “socnet”

Proposal: New internet protocol I’d call “socnet”.

  • Similar to RSS, it’s a subscription protocol delivering data via XML file format.
  • Users can create and host ‘social data’ in any tool and on any server, or using a site like Facebook.
  • Other individuals request to connect to the socnet feed of a user, who then accepts them, but can limit–at the individual level–which feed elements (files and folders) the individual can read.
  • Any tool requiring socnet data is granted it by the reading individual. So your contacts app would point at your socnet aggregator app; your calendar app, too; and so forth.
  • Status updates and media sharing are just like normal RSS, basically: a content category, but based on one entity (user, business, group) instead of a site or search.

Result: A platform-independent social networking protocol that abstracts user data out of sandboxed services.

Major Bonus: Contact data is only maintained in one data store: the user’s! No more obsolete contact details, for those to whom you subscribe. Personal calendars could be similarly driven. Anything you’d need to share and sync that currently requires manual data entry or linking.

Voice-Only Smartphone

Basic design: a brick in your pocket with a giant battery, all the RAM, CPU, and storage. A Bluetooth earbud with also a giant battery (must last a day always on).

Use cases: Leverage all the voice-activated functions of current chat bots.

User merely speaks all commands, text messages, calendar events, etc.

Bluetooth keyboard and Wi-Fi screen pairing, when you gotta type to configure or install.

End result: A smart device that never dies (if charged daily) and JUST WORKS. Talk to ‘yourself’ and let the system click icons and type on a tiny screen.

Descent 1E Condition Checker For Android

Motivation

Descent Condition Checker ScreenPlaying Descent: Journeys In The Dark (1E) can be an exercise in confusion, especially when one has several conditions in play, is a Necromancer, and is wandering through a trapped dungeon. My second app for Android, built using App Inventor, is designed to make such checks fast and error-free.

The Application

Here is a link to a ZIP of the APK file for the application:

Descent Condition Checker For Android

The Logic

The app is simple enough: click the condition button and it checks against one of three subroutines, as appropriate to the particular condition: rollBlank, rollSurge, or rollPowerEnh. Based on whether TRUE or FALSE is returned by the subroutine, a specific message is displayed in the results area at the top of the screen.

Problems

The following code is supposed to delay a bit and show some text after a button press, to confirm the press for the user:

Descent Code Block Problem

The RESULTS text change, however, does not work properly, no matter where I call for it (even if I make the text change its own procedure). I have to assume that this is a bug with App Inventor, because the exact same calls are used to make the results area change its text based on check results, as well as its background color (green for good-for-the-user results, red for bad-for-the-user results).

Credits

Descent: Journeys In The Dark is ™ and ©2011, Fantasy Flight Games, all rights reserved.

Descent Condition Checker For Android app is ©2011, David Carle Artman, CC-BY NC 3.0.

IAWA Oracles For Android

Motivation

IAWA Oracles ScreenI decided to try out Google App Inventor, being invited to the Beta. I wanted a simple enough project to get a feel for the process without becoming bogged down in complex logic or user interface (UI) design. It occurred to me that a random Oracle generator for the In A Wicked Age role-playing game by Vincent Baker would be interesting enough and maybe even useful to others.

The Application

Here is a link to a ZIP of the APK file for the application:

IAWA Oracles For Android

The Logic

App Inventor uses OpenBlocks as a visual programming environment. Very cool for beginners, but also very mouse-intensive when one has repetitious tasks (like pasting in 208 lines of text!)—I’d have liked to be able to edit a TXT or XML file to populate the Oracles lists.

Here is an image of the basic logic for the Blood And Sex Oracles button:

IAWA Oracles Logic Blocks

Nothing too fancy going on here:

  1. Copy the set-specific list to the OraclesCurrent temporary list.
  2. Call the generic procedure that populates the Oracle labels:
    1. Populate the first Oracle label element’s Text with a random Oracle from the list.
    2. Set the second label’s text to the same value as the first.
    3. While the second is the same as the first, populate the second with a random Oracle from the list.
    4. Repeat Steps 2 and 3 for the remaining two label elements, checking them against all preceding labels.
      Put another way, an Oracle label element can not contain the same Oracle text that is currently in any preceding label element.

The rest of the app is a simple UI of buttons for choosing an Oracle set (the BloodAndSex.Click event in the logic shown) and, of course, four global list variables (one-dimensional arrays) to hold the Oracle-set-specific text (the OraclesBloodAndSex in the logic shown).

Credits

In A Wicked Age is ©2007, Vincent Baker, all rights reserved.

IAWA Oracles For Android app is ©2011, David Carle Artman, CC-BY NC 3.0.

Food Bank Coordination

Challenge

Municipal food banks depend upon food donations to serve the hungry. Coordinating donors with bank locations becomes a logistical challenge:

  • Picking up donations in a timely manner, without disrupting donor business
  • Distributing donations to banks that need them most
  • Accounting for the storage space of banks
  • Transferring food between banks, if actual numbers do not align with projected needs

Use Cases

A donor registers what they have to donate on a Google map, and chooses a range of pickup time (e.g. a restaurant will usually want it to be between 2pm and 4pm; a grocery store might prefer 10pm to 2am). Options to schedule recurring pickup days, dates, and times.

A recipient registers current stock (one-time, upon setup), storage maximums by volume or weight or other? (one-time, upon setup; and if storage increased), pickup minimums by volume or weight (below which it’s not worth the bank’s costs to pick-up; adjustable as needs change), and projected need (daily, weekly; based on history, once sufficient data is accumulated).

A bank’s delivery drivers are given a “traveling salesman” shortest route to pickup donations equivalent to the bank’s projected need. When they commit to the route, those donations are not made available to other banks unless released later by the receiving bank (to be re-distributed where most needed).

Architecture

Initial setup form, as donor only or recipient/donor.

Site (donor or bank) location definition, via manual text entry, push-pin on Google map, or GPS.

Secure verification of valid bank via server check against state or municipal registries.

User deletion of “bad” donor locations -OR- “bad” donor location reporting and server-side banning.

Multiple location support, for owners of several donor businesses or managers of multiple food banks.

Route navigation interface, once a bank’s delivery drivers commit to best-route pick-ups.

Option to use less efficient routing, if necessary to deliver more balanced meals at a given bank or system-wide.

Historical data storage, server-side or locally, for need projection for a given distribution period (day, week, month?).

Optional automatic application of need projections based on historical data, with ability to adjust before submitting to server for distribution.

Costs

Application development and maintenance – Open source community? Grants?

Validation of food banks against municipal or state charters – Possibly manual labor; possibly automatic with connection to government systems.

Server-side data accumulation and re-distribution to apps – Possibly a function of a public Google map; more likely hosted via grant or by government servers.

License

Creative Commons 3.0 BY-NC-SAThis work is distributed by David Carle Artman under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.